[ncl-talk] Raster image discrepancies between versions 6.1.2 and 6.2.x

[David Brown]

Andrea,
(continued from last message: the previous message was sent
accidentally using some keyboard shortcut that I apparently invoked in
my mail program)

Passing the specific subset means NCL does not have to wade through
the whole dataset to find the relevant part. This is not directly
related to your problem, but as I will describe it does affect it.

I am presuming from the nature of your message that you are interested
in the value of specific cells in the plot. When you use raster
plotting there are three successive grids involved: the data grid,
NCL's internal rasterization grid, and (at least for raster type
output such as PNG) the workstation (output file in this case) grid.
At each step, if the number of cells along an axis do not match up,  a
form of interpolation has to take place in order to place the input
grid on the output grid. Going from a low-res to a high res grid is
not usually a problem, but if the grids are both low-res and just a
bit mis-matched, then there may be data grid cells that get left out
-- this is what was going on in your 6.1.2 plots.
The most reliable way to see the actual cells of your data is to use
the CellFill method. However, CellFill can result in very big files
especially if you use postscript or PDF. But it may work for you if
you output to a raster format like PNG. Even if you don't want to
output CellFill for your final product, writing a CellFill to PDF can
be good for debugging because you can zoom way in and look at the
individual cells.
Another thing you may want to try is to play with the resource
cnRasterSampleFactorF. Setting it to 0 causes NCL to use one raster
cell for each input data cell (assuming rectangular arrays such as you
have). However, it bases its calculations on the whole array that is
passed to it. That is the other reason for subscripting your array to
just the part you want to draw. This is also a way to get 6.1.2 and
6.2.1 to draw the same exact plot.

Anyway I could go on at length about this topic, but hopefully I
haven't been too confusing.
I will attach a modified version of your script where I tried some of
these options. I modified it so that the input and output files all
live in the same directory as the script.

Hope this helps.
 -dave






On Tue, Nov 4, 2014 at 2:21 PM, David Brown <dbrown at ucar.edu> wrote:
> Hi Andrea,
> I have spent some time looking at your issue, and I have discovered
> the immediate cause of the "noticeable differences" you see between
> NCL 6.1.2 and NCL 6.2.1 in rendering your plot. The problem is that
> when the new cairo workstations were introduced, they did not fully
> support a non-public resource that allows the raster filling routines
> to get the workstation's resolution values. When drawing a PNG file,
> this is essentially the values of wkWidthF/wkHeightF. Since the cairo
> workstation was not sending back the current information, the resource
> retained its default value of 1024. For 6.2.1 we corrected this
> omission, and now the actual value of the workstation's current
> resolution is returned. This difference accounts for the different
> appearance of the plots, and I can say with some confidence that the
> 6.2.1 version is more correct. The simplest way to see this is to
> change the wkWidth and wkHeight resources in your test script to 1024
> (the default value). Then 6.2.1 and 6.1.2 will return the same
> picture.
>
> That said, there are a couple of other points I would like to make
> about your script. First of all, you are plotting only a very small
> subset of a number of large arrays. Since this data has 1D
> coordinates, you can speed up your code immensely by sending only the
> subset you want to plot to gsn_csm_contour_map. Instead of passing
> data(n,:,:) you could use coordinate subscripting to
> pass
> data(n,{res at mpMinLatF:res at mpMaxLatF},{res at mpMinLonF:res at mpMaxLonF})
>
>
>
>
>
> On Thu, Oct 30, 2014 at 2:27 PM, David Brown <dbrown at ucar.edu> wrote:
>> Hi Andrea,
>> I do see the small but noticeable differences you are talking about,
>> and I am not sure why either. If you can send us your script and data,
>> we can try to figure out the cause. For info on uploading files, see
>> the page: http://www.ncl.ucar.edu/report_bug.shtml
>> Be sure to let me know (offline) the names of the files you upload.
>> Thanks,
>>  -dave
>>
>> On Thu, Oct 30, 2014 at 1:10 PM, Andrea Allan
>> <aallan at coas.oregonstate.edu> wrote:
>>> Hello,
>>>
>>> I am currently struggling with trying to diagnose small, but very noticeable
>>> differences between raster images (png workstation) created in NCL 6.1.2 and
>>> the newest version 6.2.1, using the exact same code and data files in both
>>> cases.  Large-scale patterns in the data are consistent; however, something
>>> has changed between the two versions of NCL that make the data shift ever so
>>> slightly (see attached images).
>>>
>>> I've perused all the changes made in the the new version of NCL, and while
>>> it is hard to pinpoint the problem, could this be related to the change in
>>> how transparency is handled in raster contouring, or the raster contouring
>>> method itself?  Searching the ncl-talk archives, I came across this
>>> statement from another raster image-related problem:
>>>
>>> "I think the problem is that the old workstation types do not understand
>>> transparency in colors."
>>>
>>> I have experimented with res at cnMissingValFillColor to no avail.  We have
>>> also looked at data resolution vs. screen resolution, and while that makes a
>>> difference within the figure, it does not solve the discrepancy between
>>> versions.  Any insight regarding this issue is greatly appreciated.
>>>
>>> Andrea
>>>
>>>
>>> ~~~
>>> Andrea M. Allan
>>> Postdoctoral Research Associate
>>> College of Earth, Ocean, and Atmospheric Sciences
>>> Oregon State University
>>> 112 Burt Hall
>>> 541-737-3427
>>> aallan at coas.oregonstate.edu
>>> ~~~
>>>
>>> _______________________________________________
>>> ncl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcode.ncl
Type: application/octet-stream
Size: 20635 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20141104/005e3ed7/attachment.obj