[Paraview] Saving Images

Moreland, Kenneth kmorel at sandia.gov
Tue Mar 1 14:35:29 EST 2011 

Greg,

I think we all agree with you here.  The discussion of the padding was not
intended to be a justification for image inconsistencies.  Rather it is
intended to help us identify what is causing the problems and try to
prevent reintroducing more grievous artifacts that the padding was
originally supposed to prevent.

-Ken 

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel




On 2/28/11 2:55 PM, "Greg Schussman" <schussman at slac.stanford.edu> wrote:

>Hi, Ken and Utkarsh.
>
>I'm not 100% sure I understand the padding.  If something special is
>needed to get nice pictures out of some misbehaving graphics cards, that
>makes sense.  However, here's my $0.02 from a user's perspective.
>
>The image produced via padding should match, pixel for pixel, the same
>image produced without any padding (except for viewport crossing
>polygons on misbehaving graphics cards).  For a specific image size in
>pixels, camera location/orientation, and field of view angle, the image
>is uniquely defined, and should look identical, whether rendered in
>ParaView, some CAD program, or a ray tracer.  In my opinion, padding is
>fine, so long as the user never knows about it.
>
>Correctness of the image is very important to what I do, especially when
>splicing images/scenes together for a movie.  For example, while testing
>and setting up a scene, I might render it at a low resolution (so save
>time and disk space), and then in a production run, rerender after
>multiply that resolution by integer factors of 2 or 3 and average down
>for fine lines and antialiased edges.  But if the original and
>downsampled images have different zooms, I'm stuck with visual
>discontinuity in my movie.
>
>In the save dialogs (screenshot or animation), I would like the default
>pixel dimensions to match the exact dimensions of the 3D view in
>paraview (or, ideally, even stay the same as the last thing I typed in,
>with a button to reset to the dimensions of the 3D view, so there's no
>need to re-type them every time a screenshot is taken).   Any padded
>numbers should happen behind the scene, and not be exposed through the
>dialogs boxes.
>
>Also, automatically adjusting resolutions to nice multiples of 16 or
>whatever makes movie codecs happy is a nice feature.  However, there are
>cases where this gets in the way.  It would be nice to have a checkbox
>so the user has the option to allow this or not.
>
>Thanks for considering this.
>
>Greg
>
>On 02/16/2011 07:54 AM, Moreland, Kenneth wrote:
>> Utkarsh,
>>
>> I'm guessing that this is more problems with the padding that is added
>> when saving animations.  I'm guessing that the padding is added because
>> graphics cards sometimes do weird things to polygons that cross the
>> viewport, and this causes noticeable artifacts when tiling images.
>>
>> I recently had to modify the behavior of the padding a bit to get
>>around a
>> similar problem when views with large aspect ratios noticeably changed
>> zoom when the padding was added
>> (http://www.paraview.org/Bug/view.php?id=9147).  I fixed it by making
>>the
>> padding proportional to the image dimensions
>> 
>>(http://paraview.org/gitweb?p=ParaView.git;a=commit;h=f87c66d4b4322743db1
>>87
>> cf3a0efeed3ffaa3e52).
>>
>> I suspect that there is a similar problem here.  When you double the
>> dimensions of the image, the padding stays the same.  Because the
>>geometry
>> projection is based on the whole rendered window, including padding, and
>> because the padding does not proportionally change with the image
>> dimensions, the zoom of the clipped saved region is different.
>>
>> -Ken
>>
>>     ****      Kenneth Moreland
>>      ***      Sandia National Laboratories
>> ***********
>> *** *** ***  email: kmorel at sandia.gov
>> **  ***  **  phone: (505) 844-8919
>>      ***      web:   http://www.cs.unm.edu/~kmorel
>>
>>
>>
>>
>> On 2/16/11 8:30 AM, "Utkarsh Ayachit"<utkarsh.ayachit at kitware.com>
>>wrote:
>>
>>> Greg,
>>>
>>> I was able to reproduce the slight zooming effect as the resolution
>>> changes. I don't understand the camera transformation code employed
>>> that well, so it will need some tracking down. However the animation
>>> resolution issue definitely sounds like an easy fix. I'll take a look.
>>>
>>> Utkarsh
>>>
>>> On Wed, Feb 9, 2011 at 4:22 PM, Greg Schussman
>>> <schussman at slac.stanford.edu>  wrote:
>>>> Hi.
>>>>
>>>> I've had some surprising results when saving images out of ParaView.
>>>>I
>>>> haven't had time to thoroughly examine results by looking at
>>>>difference
>>>> images until recently.  Here's what I found.
>>>>
>>>> When I carefully size the ParaView 3D view to, say 1280x960, and then
>>>> "File->Save Screenshot", the view looks the same.  Comparing this
>>>>with a
>>>> screenshot taken from gimp (with the rest of the gui carefully cropped
>>>> away), I find that the view is the same.  There are some pixel
>>>> differences
>>>> along thin edges, but this should be acceptable, because the way the
>>>> saved
>>>> image is rendered might not be the same way as the screen image is
>>>> rendered.  But the view is the same.
>>>>
>>>> I do encounter problems, however, when I adjust the pixel resolution
>>>>for
>>>> saving a screenshot.  If I double the resolution to 2560x1080, and
>>>>then
>>>> average that back down and compare it with the 1280x960 saved image, I
>>>> would
>>>> expect pixel differences where thin lines average down to slightly
>>>> different
>>>> antialiased colors.  However, the actual view changes as well (zooms
>>>> in), so
>>>> What I See Isn't What I get.  The view changes further if I save out
>>>>at
>>>> 3x
>>>> the original resolution (doesn't match 1x or 2x).  Again, I'd expect
>>>>to
>>>> see
>>>> pixel differences from different anti aliasing, but the view itself
>>>> shouldn't change (no zoom/pan/rotate).
>>>>
>>>> So then I investigated saving an animation frame.  Although I wouldn't
>>>> expect this to match the gimp screenshot for the same reasons that the
>>>> 1x
>>>> "save screenshot" image didn't, I would expect it to match the 1x
>>>> screenshot.  But it doesn't.  Furthermore, animation frames at 2x, and
>>>> 3x
>>>> also don't match 1x in that the view changes (zoom is different).
>>>>The
>>>> change in zoom seems consistent with the change in zoom from "save
>>>> screenshot" for 1x, 2x, and 3x.  I think that the correct thing would
>>>> be to
>>>> have all zooms match each other, regardless of pixel resolution (at
>>>> least,
>>>> for the same aspect ratio images).
>>>>
>>>> It makes sense to me that the zoom changes would be consistent between
>>>> "save
>>>> screenshot" and "save animation", because I would expect the same
>>>> routine to
>>>> do the saving.  However, I was suprised to find pixel differences
>>>> between
>>>> the 1x versions, the 2x versions, and the 3x versions.  I would expect
>>>> these
>>>> to be, pixel-for-pixel strictly identical.  To my eye, I haven't seen
>>>> any
>>>> obvious differences.  But theoretically, shouldn't each 1x pair be
>>>> identical?  Same for 2x with each other, and 3x with each other?
>>>>
>>>> Another odd thing is that "save screenshot" defaults to the resolution
>>>> of
>>>> the 3d view.  But, for some reason, "save animation" for a 1280x960 3d
>>>> view
>>>> defaults to 1259x944.   I can understand automatic tweaking of
>>>>animation
>>>> frame resolutions so that they're nice multiples of 16 or 32 or
>>>>whatever
>>>> makes video codecs happiest.   But in this case, 1280x960 is already a
>>>> perfect multiple.
>>>>
>>>> It would be really nice if all methods of saving images were
>>>>consistent
>>>> with
>>>> respect to view (zoom/pan/rotate).  It's frustrating to try piecing
>>>> movies
>>>> and transitions together from animations and screenshots, only to have
>>>> them
>>>> not align due to these inconsistencies.  It's also tedious to
>>>>constantly
>>>> have to fix the pixel resolution when saving animations because the
>>>> default
>>>> doesn't match the 3d view and the save screenshot resolution.  It's
>>>>also
>>>> frustrating to have a 3d view with the correct aspect ratio, compose a
>>>> nice
>>>> scene, save it out, have it approved, and then come back to generate a
>>>> high
>>>> resolution version and find the edges of the model cropped off because
>>>> the
>>>> zoom changed out from under me.
>>>>
>>>> All the above behavior was in 3.11.0, 64 bit, checked out a couple
>>>>days
>>>> ago,
>>>> and compiled on Fedora 14.  I apologize for so much text, but because
>>>> these
>>>> seem related to me, I figured it made sense to keep them together.
>>>>
>>>> Any thoughts?
>>>>
>>>> Thanks.
>>>>
>>>> Greg
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the ParaView Wiki at:
>>>> http://paraview.org/Wiki/ParaView
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the ParaView Wiki at:
>>> http://paraview.org/Wiki/ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.paraview.org/mailman/listinfo/paraview
>>>
>>
>>
>
>

More information about the ParaView mailing list