Configurable colour depth for rrdgraph output file ?

[oetiker]

Hi folks, new to rrdtool via Howard Jones' weathermap.

In there any way to render the PNG output of rrdgraph using a configurable colour depth?. Eg Traditional MRTG defaults to 4 bit colour depth and the typical .png it produces in the order of 1 to 4 Kb. A similiar rrdgraph uses 32 bit colour depth and it's .png is in the order of 20 to 30Kb. At slower client/server connection speeds you begin to notice the lag in the popup functionality implemented in overlib.js. For simple graphs could a smaller pallet do just as well (less time/electricty/carbon!)?.

Regards to you and your team for an excellent piece of work. Stephen

[oetiker]

[oetiker] Hi Stephen,

Yes color reduction would be a nice feature, I am unfortunately not aware of a simple way todo that. If you have input on the tech level, please let me know. for the moment I can not do much about this.

tobi

[GreenReaper]

I spent a while looking into this. Basically, cairo can't do it and isn't going to. cairo_surface_write_to_png() doesn't write optimised full-colour PNGs, let alone consider indexing them (that'd require an indexed layer type). Besides, the PNGs created by rrd-graph tend to have more than 256 colours - which also mean optipng won't reduce it.

Probably the best solution is to use, say, pngquant on your output file. Compile it on the target machine rather than installing from a package for the best performance and sizes. ImageMagick works, too (e.g. 'convert A.png -colors 256 PNG8:A.256.png'), but takes twice as long to produce larger files.

[oetiker]

Hi @GreenReaper, the pngquant folk also offer their functionality as a library ... adding this into rrdtool should not be all that difficult ... since cairo can easily provide the image in RGBA format ... this could be integrated as an extra image format into rrdtool PNG256 or something ...

My main concern is not image size though, but performance, and currently rrdtool spends a considerable amount of time compressing the png image ... I wonder if this might be even faster with pngquant.

[GreenReaper]

libpng seems to be required for the writing - but if you're willing to give it a go, I wouldn't be surprised if a PNG-8 file was faster than PNG-24. In theory, with each pixel represented by a single byte, it's three or four times less to run through the PNG compression algorithmm, for a start.

I don't know if you use alpha in rrdtool, but I think that can be retained if you need it. The quantization itself takes time, but the program reported SSE support on compilation here, and it appears to be tuneable with speed functions.

I'm coming to this from the perspective of a user of munin, which by default pre-generates a bunch of images every five minutes. Even in 2015, loading a page full of these takes time and bandwidth - user time, if you're waiting for it to load. Smaller, quickly-generated files could have an impact.

[oetiker]

and are you interested in attempting a patch ?