<div dir="ltr"><div><div><div>Hi Chris<br><br></div>gd seems like a great candidate for 8-bit rendering (which is what we want). And thanks for the insights into PIL. I will look more into the links you provided.<br><br></div>Best regards,<br></div>Jesper<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-17 19:23 GMT+01:00 Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen <<a href="mailto:jesper.webmail@gmail.com" target="_blank">jesper.webmail@gmail.com</a>> wrote:<br></div></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>We are using Matplotlib for a web service which makes PNG images on the fly for presentation on a map (web site using the web service is here: <a href="https://ifm-beta.fcoo.dk" target="_blank">https://ifm-beta.fcoo.dk</a>)<br></div><br></div>Performance and image size are two major concerns for us. We therefore save the resulting RGBA PNG to a buffer and afterwards use Pillow (PIL) to convert it to a P PNG (paletted PNG) to reduce the image size dramatically.<br></div></div></div></div></div></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>We have similar issues, though not with MPL -- in fact one reason we are not using MPL is because we want highly optimized rendering -- all the features MPL provides do add overhead...</div><div><br></div><div>And doing experiments with various rendering engines (PIL, AGG, SKIA, GD) with found that they all have pretty darn similar performance, but that performance scales pretty much with how many bytes you are pushing -- i.e. larger images take longer to render, and 8 bits per pixel is faster than 32 bits per pixel (by pretty much a factor of four, if I recall).</div><div><br></div><div>So while you are now taking a lot of time converting, you might also get faster rendering in the first place if you use 8bpp rendering.</div><div><br></div><div>But, as Thomas suggested, AGG is pretty much all about anti-aliasing and that requires more than 255 colors....</div><div><br></div><div>So: the "right" way to solve this problem is to use a non-anti-aliasing, 8bpp rendering lib. You could make a new back-end that uses that instead of AGG. ONE of the core MPLS devs (I can't remember who) suggested that MPL could use a maybe-not-the-best-quality-but-fast back end last year at SciPy, so maybe you'll get some help if you want to do it.</div><div><br></div><div>Also, a non-anti-aliasing back-end would be nice for things like contours where you can get anti-aliasing artifacts where adjacent polygons are supposed to line up exactly.</div><div><br></div><div>I suggest the libgd rendering lib:</div><div><br></div><div><a href="https://github.com/libgd/libgd" target="_blank">https://github.com/libgd/libgd</a><br></div><div><br></div><div>It's not seeing a massive amount of development, but that's because it's been around forever and is pretty darn robust and stable. It's also got an ancient, semi-ugly C API, but we can deal with that :-)</div><div><br></div><div>If you want to make a MP back end with it, I suggest you start with my Cython-based python wrapper:</div><div><br></div><div><a href="https://github.com/NOAA-ORR-ERD/py_gd" target="_blank">https://github.com/NOAA-ORR-ERD/py_gd</a><br></div><div><br></div><div>It's not terribly complete, but provides the core functionality for rendering 8 bit images, and numpy interactivity -- i.e. passing coordinates of large polygons as a numpy array, and passing the raw image data in and out as a numpy array.</div><div><br></div><div>I've also got conda packages for libgd and py_gd in our channel here:</div><div><br></div><div><a href="https://conda.anaconda.org/noaa-orr-erd" target="_blank">https://conda.anaconda.org/noaa-orr-erd</a><br></div><div><br></div><div>The recipes for those are here:</div><div><br></div><div><a href="https://github.com/NOAA-ORR-ERD/orr-conda-recipes" target="_blank">https://github.com/NOAA-ORR-ERD/orr-conda-recipes</a><br></div><div><br></div><div>Honestly, AGG has been pretty integral to MPL from the beginning (Or near beginning), so I'm not sure how hard it would be to drop in a new renderer, but I'd be glad to help.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>2) Is it better to make a separate Pillow based backend for this (Pillow is probably not as fast as AGG)?<br></div></div></div></div></div></div></div></div></blockquote></div></div></div></blockquote></span></div><div class="gmail_extra"><br></div>NOTE: we looked at using PIL for our rendering, and it was kind-of-sort of fast enough, but the rendering code, and python calls to it is all hand-written C, so it looked a lot harder to extend and optimize performance for.</div><div class="gmail_extra"><br></div><div class="gmail_extra">With py_gd, we can direct calls to the C lib form numpy arrays directly, and write time-sensitive loops in cython where there are speed bottlenecks.</div><div class="gmail_extra"><br></div><div class="gmail_extra">One issue that will take a bit of effort is colormaps -- IIUC, MPL pretty much assumes 32 bit (or 24 bit anyway) color. With 8bpp, colormaps have to be limited to 255 colors, and, in practice, you probably want to save a few "pure" colors for rendering text and the axes, etc: transparent, white, black -- a few others?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think you could get a fine colormap with, say 245 colors, saving 10 for other uses, but then you could only have one colormap in use at a time. So there may be some working around MPL's colormap code for this....</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-Chris</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br></div><div class="gmail_extra"><div><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a> voice<br>7600 Sand Point Way NE <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a> fax<br>Seattle, WA 98115 <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a> main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></font></span></div>
</blockquote></div><br></div>