[prev in list] [next in list] [prev in thread] [next in thread] 

List:       graphviz-interest
Subject:    Re: [graphviz-interest] color slightly off
From:       aaron brick <bricktron () gmail ! com>
Date:       2010-05-22 6:00:00
Message-ID: AANLkTim9UE6B_2YCb0-EkTzrcn4rDwM72ftG7qtNUHuN () mail ! gmail ! com
[Download RAW message or body]

very interesting details. i don't think graphviz should be responsible
for the crushing, but i do think true white needs to be in the color
palette of output images, not least if it's specified.

as it happens JPG is a decent compromise for this application - the
white is correct, the files not too huge and the compression artifacts
not too visible. i really only need maybe 16 greys here.

i surely appreciate your support and willingness to debate this!
aaron.


--   aaron brick
--   aaron@lithic.org
--   http://www.lithic.org





On Mon, May 17, 2010 at 3:22 PM, John Ellson <ellson@research.att.com> wrote:
> On 05/17/2010 11:52 AM, Ryan Schmidt wrote:
>>
>> On May 17, 2010, at 09:42, John Ellson wrote:
>>
>>
>>>
>>> I think what Aaron is seeing is the default PNG files generated with
>>> cairo which are 24bits per pixel, or 32 if the alpha channel is retained.
>>>  GIFs (or PNGs) generated by gd with indexed colors are closer to 8bits per
>>> pixel.
>>>
>>> These examples show some of the variations in size:
>>>
>>>
>>> $ echo "digraph {hello->world}"  ...
>>>
>>>    | dot -Tpng:cairo:cairo | wc -c  # antialiased
>>> 6918
>>>    | dot -Tpng:cairo:gd | wc -c      # anti-aliased
>>> 6900
>>>    | dot -Tpng:gd:gd | wc -c          # not anti-aliased
>>> 903
>>>
>>>    | dot -Tgif:cairo:gd | wc -c       # anti-aliased, but can run out of
>>> indexed colors quickly
>>> 2815
>>>    | dot -Tgif:gd:gd | wc -c           # not anti-aliased
>>> 1016
>>>
>>
>> Ok, I see similar results. I note that the gd:gd output is smaller as a
>> PNG than as a GIF, as I suspected.
>>
>> I haven't kept up with Graphviz changes; I didn't notice when it became
>> possible to specify two colon-separated strings after the image format, and
>> don't know what the difference is between "-Tpng:cairo:cairo" and
>> "-Tpng:cairo:gd".
>>
>
> The middle field is the "renderer" plugin that draws lines, polygons, etc.,
> to an in-memory bitmap, the last field is the plugin the "device" plugin
> that takes it from bitmap to file (or window, in the cases of -Tx11 or
> -Tgtk).
>
> The "device" plugin was introduced primarily for a place to handle the event
> loops for windows, but the structure
> permitted the hack of using GIF file formatting from gd, with the cairo
> renderer, after a trivial conversion of the internal bitmap representation.
>
> -Tpng:cairo:cairo uses the native PNG "device from libcairo.
>>
>> I don't even get gif:gd or gif:cairo as options on my Mac; I only get
>> gif:quartz. For png, I have png:gd, png:quartz and png:cairo available. Do I
>> need to do something special to get those other GIF output options to
>> appear?
>>
>
> Sounds like you don't have the gd library available?
>
>> Comparing the output of gif:quartz and png:quartz, I note that gif:quartz
>> generates an image with 32 grays in the palette, but png:quartz generates a
>> 24-bit image -- but if I convert that to 8-bit, it shows a color palette
>> with 252 grays. Wouldn't that account for some difference in size too? Why
>> is the PNG getting so many different grays and the GIF is getting so few?
>>
>
> I didn't write the quartz plugin, but to me the question is rather, why so
> many grays for GIFs?   It sounds like it might be using some preset color
> tables?
>
> It could be that when converting from truecolor, when antialiased lines
> cross you get pixels with additional shades of gray,
> it wouldn't take long to fill up the index table if this is happening.
>
>> One could use ImageMagick or similar to convert the Graphviz PNGs to 8-bit
>> and to have fewer colors, and thus take up less space.
>>
>
> Converting from truecolor (24 per pixel) to indexed color with 256 colors
> max is non-trivial code, quite interesting, but computationally expensive.
>  There is code available for this in  gdImageTrueColorToPalette() in libgd.
>  I currently only use
> it for -Tgif:cairo:gd, but I could probably also use it for -Tpng:cairo:gd
> if you want smaller antialiased PNG images?
>
> This would only work  for graphs with limited color usage as basically each
> graph color uses 4 variants of that color for anti-aliasing against the
> background.
>
> Or you could use ImageMagick, if it provides this capability?  I don't know
> for sure that it does.
>
> John
>
>
>
>

_______________________________________________
graphviz-interest@research.att.com
https://mailman.research.att.com/mailman/listinfo/graphviz-interest
[prev in list] [next in list] [prev in thread] [next in thread]