<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="+1"><font face="Droid Serif">Hi.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Any thoughts?<br>
<br>
Thanks.<br>
<br>
Greg<br>
</font></font>
</body>
</html>