[Paraview] Saving Images

[Utkarsh Ayachit]

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
>
>