Hi Jonathan,
Very interesting (and complete!) analysis. I'll have to ponder this
for a bit to fully understand how/where/why the differences arise, and
what can be done about it. But to answer your immediate questions:
> - It would be nice if the line thickness/colors of primitives didn't
> "wash out" as much in the Cairo driver.
> - Are these the only settings to interact with the driver for png
> images, or are there other settings/resources that can be tweaked
> (like antialias or density) in the driver? Perhaps internally, the
> width of primitives could be boosted a bit when the Cairo driver is
> being used.
Currently there are no other PNG resources, other than image size. As
I recall offhand, the cairo driver does not provide much direct
control over PNG-specific output details, like quality or compression,
but we could provide resources to control antialiasing, which I
suspect is the source of the "wash out". I'll file a feature-request
ticket on this so we don't loose the thought.
> - Finally, is there any way to get rid of the "000001" in the png
> file that is produced?
Yea, the "000001" is an annoyance to just about everyone. As you
likely know, PNG does not support multiple images per file, and some
scheme like the sequence numbers is needed when users are generating a
series of plots. We have a ticket on file already to modify the code
to eliminate the sequence number when there is only one plot generated
from a script.
Thanks again for sharing your observations.
Rick
On Jun 3, 2010, at 6:17 PM, Jonathan Vigh wrote:
> Hi Rick, Joe, and all,
>
> I'm also looking into using the new png driver for my production
> system (TC model guidance plots). I haven't completed the testing
> for the guidance plot style yet, but I've just conducted a test for
> another type of plot that has a lot of detail (small fonts, lots of
> primitives, etc.), so I thought I'd report my results and add a few
> more questions.
>
> Here's what I did to make the Cairo png files:
> wks_type = "png"
> wks_type@wkWidth = 1600 ; default is 1024 by 1024
> wks_type@wkHeight = 1600
>
> wks = gsn_open_wks(wks_type, foodir, fooname) ; Open a
> workstation.
>
> The resulting filenames are prefixed with "cairo" and a number
> indicating the wkWidth and wkHeight. I've made the files available
> for viewing at:
> ftp://ftp.ucar.edu/pub/mmm/jvigh/cairo_test/
> In that directory, you can also compare file sizes.
>
>
> To compare with the result of ImageMagick's 'convert' command, I
> generated a postscript file and then used the following syntax:
> convert -geometry 600x600 -density 500 -trim -rotate 270
> $base".ps" $base".png"
>
> The resulting filenames have the prefix "convert" and two numbers
> representing the geometry and density values used, respectively.
>
>
> In general, I find the Cairo-generated plot files to be larger and
> crisper than the "converted" plot files for similar values of
> geometry. A plot generated with a wkWidth of 800 in the Cairo driver
> is actually larger than a "converted" plot created with a geometry
> of 1024. However, the "converted" plots seem a bit fuzzier than the
> Cairo plots. Also, polylines seem to show up brighter and thicker in
> the "converted" plots than in the Cairo plots. So depending on your
> plot style and desired aesthetic, it seems there could be advantages
> to either method. The postscript file seems to have the thicker
> polylines and brighter colors, with sharper fonts. So besides the
> fuzziness, it seems the "converted" plot files are more faithful to
> the postscript version (as viewed in ghostview).
>
> To see a good example, compare:
> ftp://ftp.ucar.edu/pub/mmm/jvigh/cairo_test/convert_temporal_1600_500.png
> to
> ftp://ftp.ucar.edu/pub/mmm/jvigh/cairo_test/
> cairo_temporal_1024.png
>
> As far as file sizes go, it seems that for comparable size, the
> Cairo-generated plot is less than half the size of the "converted"
> plot file. Using higher density values in 'convert' has little
> affect on the resulting file size, but does add to the processing
> time.
>
> I noticed that if the Cairo-generated png is blown up to a large
> size, say 1600 x 1600, the image file looks rather disturbed because
> the browser displays a reduced version. The full version is actually
> still clear however.
>
>
> So in light of all this, I have the following questions and comments:
>
> - The smaller png file sizes produced by the Cairo driver are
> certainly nicer from a production standpoint (if you're going to be
> making and storing thousands of these).
> - It would be nice if the line thickness/colors of primitives didn't
> "wash out" as much in the Cairo driver.
> - Are these the only settings to interact with the driver for png
> images, or are there other settings/resources that can be tweaked
> (like antialias or density) in the driver? Perhaps internally, the
> width of primitives could be boosted a bit when the Cairo driver is
> being used.
> - Finally, is there any way to get rid of the "000001" in the png
> file that is produced?
>
> Thanks!
> Jonathan
>
>
>
> Rick Brownrigg wrote:
>>
>> Hi Joe,
>>
>> The PNG output is created directly with a native driver based upon
>> cairographics. So yes, it sounds like it might be of value in your
>> situation and save you some hassle.
>>
>> Rick
>>
>> On Jun 3, 2010, at 3:32 PM, Joe Grim wrote:
>>
>>
>>> Hi,
>>>
>>> I was wondering if you could tell me how the new PNG output is
>>> created
>>> in NCL 5.2.0? Is it first created in a vector graphics format
>>> (e.g.,
>>> cgm) and then converted to PNG internally? Or is it created
>>> natively,
>>> skipping a conversion step?
>>>
>>> The reason I ask this question is that I work on a project that
>>> currently uses NCL and RIP to create thousands of vector graphics
>>> files,
>>> and then we need to convert them all using ImageMagick's "convert"
>>> program. If the newest version of NCL skips the conversion step in
>>> creating the PNG files, this might save us a lot of computing time.
>>>
>>> Thank you in advance for your response.
>>>
>>> Joe Grim
>>> --
>>> NCAR - RAL
>>> FL2 Rm 2068
>>> (303) 497-8397
>>> _______________________________________________
>>> ncl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Fri Jun 4 10:33:35 2010
This archive was generated by hypermail 2.1.8 : Mon Jun 07 2010 - 16:48:44 MDT
