Re: [ferret_users] subsampling as qualifier

["Ansley C. Manke" <ansley.b.manke@xxxxxxxx>]

Hi,

We've thought about this as well.  For performance and file size control in making images, one would always want to load the least data into memory, and send the least amount of data to the graphics calls, relative to the resolution of the graphics image.

As noted in the last message, the issue for use of strides in reading data, is that the _expression_ could come from multiple grids, so strides have to be applied to the grids as the data is being requested. 

Once data has been read and the _expression_ computed, the amount of data sent to the graphics call could be reduced by something like a /XRES= /YRES= qualifier.  For a SHADE command the range of values shown would change if we happened to skip the extreme values in the decimation.  For a FILL or CONTOUR, there's interpolation done to compute the contour lines.  If the data is sub-sampled before sending the data to the graphics code, that subsampling could result in different graphics results.

Ansley

On 9/29/2016 12:29 AM, Ryo Furue wrote:

Hi Ansley and Patrick,

I've been long wondering about the same problem as Patrick. But, my motivation may be a bit different. To me the main problem is the size of the vector graphics.  PostScript images from high-resolution data can be unbearably large.

Your idea does sound like a convenient method for reading data using strides, when the variables being plotted are file variables.  However if the SHADE plot is showing a more complex _expression_ perhaps involving combinations of variables regridded to a new grid, then the qualifier would be ambiguous.

So, I was wondering if strides or resolution or both can be an option to the SHADE and FILL commands.  After all potential computations, these commands find out the grid of the field they are going to plot.  So, it's best to ask them to regrid.

Of course you can always achieve the same result by writing a script such as Ansley showed us, but it's a bit more tedious than

    FILL/xres=600/yres=400  some_expression

Regards,

Ryo

It may be more cumbersome, but it is really necessary to to attach the striding information to the file variables or their grids.

Certainly a script can set up the striding according to the size of the grid and the output resolution of the image. Here's an example. Similar logic could be used to define a stride and use the SET AXIS/STRIDE command, or to define strides on a sub-region of the grid.

yes? let xres = 600
yes? let yres = 400

yes? let nx = `var,return=isize`
yes? let ny = `var,return=jsize`

yes? let istride = MAX(1,INT(nx/xres + 0.5))
yes? let jstride = MAX(1,INT(ny/yres + 0.5))

yes? define symbol region_spec = [i=1:`nx`:`istride`,j=1:`ny`:`jstride`]
yes? shade var($region_spec), lon2D($region_spec), lat2D($region_spec)

-Ansley