If your intent is to have this bug fixed, I'll leave that to others to
discuss.
If your intent is to get your work done, here's how I've accomplished
the same end for years.
Image outputs the collection of objects that were input to it along
with any (like AutoAxes) it creates internally, from its leftmost
output. It outputs the current Camera (point of view) through its
normally exposed rightmost output.
If you use Caption, Colorbar, Legend, you need to use ScaleScreen to
correct them for final output as they won't properly scale using the
following method.
So, feed the Objects to ScaleScreen. Tell ScaleScreen double the final
resolution desired (width) (if you want 1000, say 2000 here). Feed the
ImageCamera to ScaleScreen.
Feed the ImageCamera also to UpdateCamera and set UpdateCamera's
resolution to the same number as above. (Obviously, both could be
driven by an Integer interactor).
Output of ScaleScreen and UpdateCamera goes to Render.
Render to Reduce. I use '2.0' for factor.
Output of Reduce to a Route used to turn on/off actual output of
rendered image file (esp for testing or interactive sessions). Add a
Selector on a Control Panel to let the user flip this switch.
Output of Route (when Route flag is 1) sends rendered image to
WriteImage wherein you set the filename, file type, etc. I data-drive
the filename from some upstream Format driven by inputs that allow the
user to redirect the path or filename.
Why UpdateCamera and Reduce? Because by doubling the resolution of the
Image Camera in UpdateCamera, then halving in Reduce, you get cheap but
effective antialiasing. Up to the limits of memory, you could triple
the resolution then Reduce by 3, and so on. It becomes less cheap as
you go up since the very large image being Rendered will eventually
crash your server.
If you aren't depending on Image to create AutoAxes, you can bypass it
and send the objects straight to Render. You can build your own camera
with Camera (!) or Import a previously exported 'camera.dx' file that
you like. This is good for 'locking down' a view, in Tinseltown
parlance. In a long production run, no sense taking the time and cache
space to let Image render an image no one will see. You can hook up a
Display, with a Route, to inspect that things are working as you want
(to output of Render, or of Reduce).
On Monday, Mar 29, 2004, at 05:02 America/New_York, Wolfgang Braun
wrote:
I am using Image to display some data and have enabled the recording
facility
so that a (higher resolution) copy of the screen output is saved into
a tiff
file (recordEnable selected in the Image module configuration, Value
set to 1
). When I save the net and reload it, the recordEnable input of Image
is
unselected and the Value set to 0. I suspect this is a bug, not a
feature.
I would like to fix it for now by changing the corresponding values of
the
