| Plotting results from z-buffer are diffrenet than xwindow. [message #89017] |
Tue, 15 July 2014 06:46  |
jlpippitt
Messages: 5
Registered: July 2014
|
Junior Member |
|
|
Z buffer seems to be enhancing our plots of radar imagery. Plotting in the x-window gives us the correct result. We produce a lot of imagery so using Z-buffer is necessary. Is there a away to make a z_buffer image appear the same as an x window image.
Thank you,
Jason
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89018 is a reply to message #89017] |
Tue, 15 July 2014 07:13  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
jlpippitt@comcast.net writes:
> Z buffer seems to be enhancing our plots of radar imagery. Plotting in the x-window gives us the correct result. We produce a lot of imagery so using Z-buffer is necessary. Is there a away to make a z_buffer image appear the same as an x window image.
The Z-buffer uses a slightly different character size than the normal
display device. And, unfortunately, this affects things like the plot
margins and regions, which are expressed in character size units. To
make sure everything "aligns", you have to make sure you position your
graphics with the POSITION keyword. Otherwise, you won't be able to
align them with your images, etc.
Almost all of this is done for you, if you were to use Coyote Graphics
routines to display your data. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89019 is a reply to message #89018] |
Tue, 15 July 2014 11:57 |
jlpippitt
Messages: 5
Registered: July 2014
|
Junior Member |
|
|
On Tuesday, July 15, 2014 10:13:09 AM UTC-4, David Fanning wrote:
>
>
>
>> Z buffer seems to be enhancing our plots of radar imagery. Plotting in the x-window gives us the correct result. We produce a lot of imagery so using Z-buffer is necessary. Is there a away to make a z_buffer image appear the same as an x window image.
>
>
>
> The Z-buffer uses a slightly different character size than the normal
>
> display device. And, unfortunately, this affects things like the plot
>
> margins and regions, which are expressed in character size units. To
>
> make sure everything "aligns", you have to make sure you position your
>
> graphics with the POSITION keyword. Otherwise, you won't be able to
>
> align them with your images, etc.
>
>
>
> Almost all of this is done for you, if you were to use Coyote Graphics
>
> routines to display your data. :-)
>
>
>
> Cheers,
>
>
>
> David
>
> --
>
> David Fanning, Ph.D.
>
> Fanning Software Consulting, Inc.
>
> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>
> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
David,
Thank you for your response. I think z-buffer is applying some kind of smoothing to the data. Holes appear in a precipitation field in the x-window (which is the true representation of the data) while the images created with z-buffer the holes are filled in (maybe nearest pixel smoothing). I think it would be beneficial to see the images I am referring to. Is there a way to post images on here?
Thank you,
Jason
|
|
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89022 is a reply to message #89020] |
Wed, 16 July 2014 04:34 |
jlpippitt
Messages: 5
Registered: July 2014
|
Junior Member |
|
|
On Tuesday, July 15, 2014 3:02:36 PM UTC-4, David Fanning wrote:
>
>
>
>
>> Thank you for your response. I think z-buffer is applying some kind of smoothing to the data. Holes appear in a precipitation field in the x-window (which is the true representation of the data) while the images created with z-buffer the holes are filled in (maybe nearest pixel smoothing). I think it would be beneficial to see the images I am referring to. Is there a way to post images on here?
>
>
>
> I seriously doubt there is smoothing going on in the Z-buffer. Are you
>
> using the Z-buffer for actual buffering, or have you turned this off and
>
> are just using the Z-buffer as another graphics window? Have you set the
>
> size of the Z-buffer to match the size of your graphics window?
>
>
>
> There is no way I know of to post images, here, but I doubt looking at
>
> an image would be helpful anyway. It would probably be more helpful to
>
> look at your code.
>
>
>
> Cheers,
>
>
>
> David
>
>
>
> --
>
> David Fanning, Ph.D.
>
> Fanning Software Consulting, Inc.
>
> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>
> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
David,
Here is the code for the two plotting procedures. The resulting plots are different.
xwindow plotting procedure:
radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
rsl_plotsweep_from_radar,radar,/bgw,window=600,f='CZ',/new,m axrange=200,SWEEP_INDEX=0
zbuff plotting procedure:
radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
thisDevice = !D.Name
Set_Plot, 'Z', /COPY
Device,Set_Resolution=[600,600],Set_Pixel_Depth=24,Decompose d=1,Z_Buffer=0
Erase
rsl_plotsweep_from_radar,radar,bgw,window=600,f='DZ',new,max range=200,SWEEP_INDEX=0
snapshot = TVRD()
TVLCT, r, g, b, /Get
Device, Z_Buffer=1
Set_Plot, thisDevice
image24 = BytArr(3, 600, 600)
image24[0,*,*] = r[snapshot]
image24[1,*,*] = g[snapshot]
image24[2,*,*] = b[snapshot]
write_png,'test.png',image24,r,g,b
Thank you,
Jason
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89023 is a reply to message #89022] |
Wed, 16 July 2014 05:25 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
jlpippitt@comcast.net writes:
> Here is the code for the two plotting procedures. The resulting plots are different.
>
> xwindow plotting procedure:
> radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
> rsl_plotsweep_from_radar,radar,/bgw,window=600,f='CZ',/new,m axrange=200,SWEEP_INDEX=0
>
> zbuff plotting procedure:
> radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
> thisDevice = !D.Name
> Set_Plot, 'Z', /COPY
> Device,Set_Resolution=[600,600],Set_Pixel_Depth=24,Decompose d=1,Z_Buffer=0
> Erase
> rsl_plotsweep_from_radar,radar,bgw,window=600,f='DZ',new,max range=200,SWEEP_INDEX=0
> snapshot = TVRD()
> TVLCT, r, g, b, /Get
> Device, Z_Buffer=1
> Set_Plot, thisDevice
> image24 = BytArr(3, 600, 600)
> image24[0,*,*] = r[snapshot]
> image24[1,*,*] = g[snapshot]
> image24[2,*,*] = b[snapshot]
> write_png,'test.png',image24,r,g,b
Well, I don't see anything obviously wrong with the code, although I
would have certainly replaced all of this:
> snapshot = TVRD()
> TVLCT, r, g, b, /Get
> Device, Z_Buffer=1
> Set_Plot, thisDevice
> image24 = BytArr(3, 600, 600)
> image24[0,*,*] = r[snapshot]
> image24[1,*,*] = g[snapshot]
> image24[2,*,*] = b[snapshot]
> write_png,'test.png',image24,r,g,b
with this:
void = cgSnapshot(File='test.png', /NoDialog)
Set_Plot, thisDevice
Or, at the very least, with this:
image24 = TVRD(True=1)
write_png,'test.png',image24,r,g,b
Set_Plot, thisDevice
Do you find anything different if you leave the Device, Z_Buffer=1
command out of the sequence?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89024 is a reply to message #89023] |
Wed, 16 July 2014 05:53 |
jlpippitt
Messages: 5
Registered: July 2014
|
Junior Member |
|
|
On Wednesday, July 16, 2014 8:25:05 AM UTC-4, David Fanning wrote:
> writes:
>
>
>
>> Here is the code for the two plotting procedures. The resulting plots are different.
>
>>
>
>> xwindow plotting procedure:
>
>> radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
>
>> rsl_plotsweep_from_radar,radar,/bgw,window=600,f='CZ',/new,m axrange=200,SWEEP_INDEX=0
>
>>
>
>> zbuff plotting procedure:
>
>> radar=rsl_anyformat_to_radar('/gvs2/gpmgv_data/gpmgv/KARX/1C UF/2014/0708/KARX_2014_0708_193306.uf.gz')
>
>> thisDevice = !D.Name
>
>> Set_Plot, 'Z', /COPY
>
>> Device,Set_Resolution=[600,600],Set_Pixel_Depth=24,Decompose d=1,Z_Buffer=0
>
>> Erase
>
>> rsl_plotsweep_from_radar,radar,bgw,window=600,f='DZ',new,max range=200,SWEEP_INDEX=0
>
>> snapshot = TVRD()
>
>> TVLCT, r, g, b, /Get
>
>> Device, Z_Buffer=1
>
>> Set_Plot, thisDevice
>
>> image24 = BytArr(3, 600, 600)
>
>> image24[0,*,*] = r[snapshot]
>
>> image24[1,*,*] = g[snapshot]
>
>> image24[2,*,*] = b[snapshot]
>
>> write_png,'test.png',image24,r,g,b
>
>
>
> Well, I don't see anything obviously wrong with the code, although I
>
> would have certainly replaced all of this:
>
>
>
>> snapshot = TVRD()
>
>> TVLCT, r, g, b, /Get
>
>> Device, Z_Buffer=1
>
>> Set_Plot, thisDevice
>
>> image24 = BytArr(3, 600, 600)
>
>> image24[0,*,*] = r[snapshot]
>
>> image24[1,*,*] = g[snapshot]
>
>> image24[2,*,*] = b[snapshot]
>
>> write_png,'test.png',image24,r,g,b
>
>
>
> with this:
>
>
>
> void = cgSnapshot(File='test.png', /NoDialog)
>
> Set_Plot, thisDevice
>
>
>
> Or, at the very least, with this:
>
>
>
> image24 = TVRD(True=1)
>
> write_png,'test.png',image24,r,g,b
>
> Set_Plot, thisDevice
>
>
>
> Do you find anything different if you leave the Device, Z_Buffer=1
>
> command out of the sequence?
>
>
>
> Cheers,
>
>
>
> David
>
>
>
>
>
> --
>
> David Fanning, Ph.D.
>
> Fanning Software Consulting, Inc.
>
> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>
> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
David,
I tried both your suggestions and the result is a red background with black data points. Not the type of output I am looking for. Leaving Device, Z_Buffer=1 out of the sequence does not make a difference.
Thank you for your help,
Jason
|
|
|
|
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89027 is a reply to message #89026] |
Wed, 16 July 2014 11:56 |
jlpippitt
Messages: 5
Registered: July 2014
|
Junior Member |
|
|
On Wednesday, July 16, 2014 1:12:29 PM UTC-4, Mike Galloy wrote:
> On 7/16/14, 7:26 AM, David Fanning wrote:
>
>> OK, what version of IDL are you using? I have assumed it is possible
>
>> to actually put the Z-graphics buffer in 24-bit, color decomposed
>
>> mode. The results you describe are what I would expect if that
>
>> *wasn't* possible!
>
>
>
> 24-bit Z buffer added in IDL 6.4. Could be a very old IDL?
>
>
>
> Mike
>
> --
>
> Michael Galloy
>
> www.michaelgalloy.com
>
> Modern IDL: A Guide to IDL Programming (http://modernidl.idldev.com)
>
> Research Mathematician
>
> Tech-X Corporation
I tried it with IDL version 6.3 and 8.2, both give the same result. Check out the images in question on the link below. They were created from the same data file, one in Z-buffer and one in x-window.
http://gpm-gv.gsfc.nasa.gov/Radar/zbuff_ZZ.gif
Thank you,
Jason
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89028 is a reply to message #89027] |
Wed, 16 July 2014 13:30 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
jlpippitt@comcast.net writes:
> I tried it with IDL version 6.3 and 8.2, both give the same result. Check out the images in question on the link below. They were created from the same data file, one in Z-buffer and one in x-window.
>
> http://gpm-gv.gsfc.nasa.gov/Radar/zbuff_ZZ.gif
Well, the images look exactly like you would expect if you don't pin the
data coordinate space down by using the position keyword with what I
presume is a Map_Set command in your drawing program. That was my
original suggestion. The "smoothing" effect might go away if you fix
that problem.
Or, the smoothing effect could also be caused by possibly not using the
same number of colors in the X device and Z-graphics buffer. Do you have
some kind of pre-1970s code in your IDL start-up file that somehow
restricts the number of colors you are using? It looks to me like
something fewer than 256 colors are being used on the display device.
You could check by doing a "HELP, r" after you issue this command:
tvlct, r, g, b, /Get
Make sure these vectors are the same size in both devices.
How are you specifying your drawing colors?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89030 is a reply to message #89028] |
Wed, 16 July 2014 16:12 |
bkelley_1
Messages: 2
Registered: July 2014
|
Junior Member |
|
|
On Wednesday, July 16, 2014 4:30:45 PM UTC-4, David Fanning wrote:
> Well, the images look exactly like you would expect if you don't pin the
>
> data coordinate space down by using the position keyword with what I
>
> presume is a Map_Set command in your drawing program. That was my
>
> original suggestion. The "smoothing" effect might go away if you fix
>
> that problem.
>
I am a coworker of Jason's and the guilty party who wrote rsl_plotsweep, the drawing program in question. It was my first endeavor at writing a drawing program, and it is less than elegant. The MAP_SET call looks like this:
maxrange_meters = maxrange * 1000. ; km to meters
meters_to_lat = 1. / 111177.
meters_to_lon = 1. / (111177. * cos(radar_lat * !dtor))
nb = radar_lat + maxrange_meters * meters_to_lat
sb = radar_lat - maxrange_meters * meters_to_lat
eb = radar_lon + maxrange_meters * meters_to_lon
wb = radar_lon - maxrange_meters * meters_to_lon
map_set, radar_lat, radar_lon, limit=[sb,wb,nb,eb],/grid, advance=advance, $
charsize=charsize, color=color, _extra=extra
> Do you have some kind of pre-1970s code in your IDL start-up file that somehow
>
> restricts the number of colors you are using? It looks to me like
>
> something fewer than 256 colors are being used on the display device.
As to the color table, I simply loaded the colors I wanted into the table as follows:
r = indgen(256)
g = r
b = r
r[0:16]= [0,102,153, 0, 0, 0, 0, 0, 0,255,255,255,241,196,151,239,135]
g[0:16]= [0,102,153,218,109, 0,241,190,139,253,195,138, 0, 0, 0, 0, 35]
b[0:16]= [0,102,153,223,227,232, 1, 0, 0, 0, 0, 0, 0, 0, 0,255,255]
; Make the top color white for axes and grids.
r[255] = 255
g[255] = 255
b[255] = 255
tvlct, r, g, b ; load colortable.
The actual plotting is done bin-by-bin for each radar ray. I use POLYFILL to fill an area equivalent to the size of the radar bin at a particular map coordinate. Nothing fancy, just:
polyfill, lon, lat, color=coloray[ibin],/data
where lon and lat are 4-element vectors containing the map coordinates, and coloray is an array of color table indices representing the data for the current ray.
The same program is being used for the X device and Z-buffer.
Thanks,
Bart
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89031 is a reply to message #89030] |
Wed, 16 July 2014 17:16 |
Karl[1]
Messages: 79
Registered: October 2005
|
Member |
|
|
Since the colors look right, I don't think it is a color issue. But Jason set DECOMPOSED to 1 before calling Bart's function for the Z device. In order for polyfill to use a color index into the color table for a color, I think the device needs to have DECOMPOSED set to 0.
Bart, do you do a DEVICE, DECOMPOSED=0 in your function?
What I really think is happening is rasterization differences for polyfill on the two devices. The X (or WIN) device would likely use hardware-assist to draw polygons. On the Z device, I would think that it uses (IDL) software to perform the rasterization.
Regardless of the details of the device implementations, the important point is that the rasterization paths are different, and that means that each implementation will make different decisions about what pixels to turn on when drawing lines or shapes.
For example, if one of these radar bins is so small that it barely covers a pixel on the target device, the rasterizer needs to make a decision about whether to draw that pixel or not. More generally, whenever a polygon covers a fraction of a pixel, a decision must be made about that pixel.
Anyway, the software implementation for the Z device looks like that it *might* be making decisions that turn on more pixels than the X device. That's what I gather from comparing the two images.
Another observation that supports this idea is that the dotted line styles are rendered differently between the two devices.
I can't think of an easy way to verify this other than perhaps drawing a simple shape like a large rectangle with non-orthogonal sides on the X and Z devices and comparing the images to see how many rasterization differences there are by XORing the images. Could also try it for very small rectangles and see if there are significant differences. In other words, simplify the dataset to a few examples for easier comparison.
If that turns out to be the problem, then I might suggest separating your radar bins in terms of size and draw only the ones larger than a pixel with polyfill. The ones that are smaller can be drawn with something that sets only a single pixel. You might have to play with this threshold. For example, anything bigger than 4 square pixels can be done with polyfill, and then draw a single pixel for the others, etc.
The IDL documentation for polyfill suggests that there are rules about interior filling and to avoid them, use DRAW_ROI. You could try using DRAW_ROI to see if the polygon fill gives more consistent results without separating. If you still need to draw the sub-pixel bins differently, DRAW_ROI has a point primitive.
I can't think of any other approaches at the moment. I'm sort of surprised at how different the Z device is from the others in this respect. I would have expected some pixels to be different, but not this many.
Hope this helps (and is half-right)
|
|
|
|
| Re: Plotting results from z-buffer are diffrenet than xwindow. [message #89046 is a reply to message #89031] |
Thu, 17 July 2014 16:48 |
bkelley_1
Messages: 2
Registered: July 2014
|
Junior Member |
|
|
Karl, thanks for your detailed and informative explanation, as well as your suggestions on how to proceed.
I do use DEVICE, DECOMPOSED=0. I tried your advice on drawing a single polygon on the map setting, using different sizes, but didn't see a significant difference in appearance. Of course I was only eye-balling the images--I need to do some quantitative comparisons as you suggest. Your explanation of the rasterization issue really makes sense.
This is an interesting problem, and I will continue experimenting.
Thanks to all for your help.
Bart
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
