[gnuastro-devel] [task #14363] Change the default behaviour of --scale in ImageWarp

[Lee Kelvin]

Follow-up Comment #2, task #14363 (project gnuastro):

Thank you for your detailed reply. As we have discussed, I do not consider
this issue to be a misunderstanding, but rather something more fundamental in
the way image manipulation with respect to scaling should operate. However, I
find your suggestions to add new arguments which do behave in such a manner to
be good compromise if I'm the only one who sees an issue with the current
operation.

With regards continuous space vs discrete pixel space, I am more than happy
for ImageWarp to internally treat data as laying on a continuous axis. This is
as it should be for the purposes of maintaining accuracy during potentially
multiple image transformations. However, what I think you have missed in my
original post is that when it comes to the point at which an output file must
be saved, ImageWarp will *always* have to make a conversion back into
_discretised pixel space_. In that sense, yes, I am thinking in terms of
discrete pixel space because this is fundamentally how our data is observed at
the telescope, saved, and output. When a photon hits a CCD pixel, we have no
further information on whereabouts across the area of this pixel the photon
was absorbed. Therefore, our input data is discretised by design from its
inception. Again, to re-iterate what I wrote above, it then makes sense to
treat an input image as _continuous_ for the purposes of image manipulation,
pixel mixing, resampling, etc, but ultimately the final output *must* be
re-discretised by the software.

However, I think the discussion of continuous vs discrete space, whilst
interesting, does not fully address the issue I originally raised here. I am
also well aware that the bottom left corner of the first pixel in a FITS image
has coordinates [0.5,0.5] as defined by the FITS standard, and I also do not
think that this addresses the issue either.

Lets work in continuous space. My x-axis begins at 0.5 and ends at 8.5, as per
the FITS standard definition. Using the real numbers along this axis we now
have a continuous space within which to operate of length 8.5 - 0.5 = 8.0. I
now want to scale my continuous spatial axis by 1/3. Performing the
calculation, my continuous spatial axis is now only of length 2.666. All my
image manipulation is now finished. I now want to save this file back out to a
FITS image, however, the length of the axis is not an integer, which makes it
impossible to write an image - what do we do? The current mode of operation
just begins chopping up the image pixel-by-pixel, starting in the bottom-left
corner, and when it gets to the last one it says "tough luck, you don't have a
full pixel area, so we're just going to have to upgrade you from having an
area of 0.666 pixels to 1 pixel." Why should the final pixel alone be singled
out and penalised for an image transformation which affected the entire image?
This imposes all of the image manipulation sizing discrepancy onto the final
pixel. 

Why do I believe this to be counter-intuitive? Consider the example FITS file
I proposed in my original post: 8 pixels in a row with each pixel having the
value 1. The input image is flat and homogeneous. After scaling using the
current set-up of ImageWarp, the homogeneity of the image has been lost.
Instead, the final pixel is now different from the remaining pixels, imposing
a modification of a previously flat and homogeneous dataset. 

My suggestion is that it is fairer to penalise *all* pixels by some small
amount by stretching the continuous spatial axis from 2.666 back up to 3, such
that it maps perfectly onto a discretised pixel space. Or, in effect, you
modify your initial scaling value such that only one transformation need take
place.

In summary, I do not believe that a modification of ImageWarp in such a manner
as proposed would cripple ImageWarp for science use. Indeed, I find the
current operation to be unexpected and violating the principle of least
surprise, making science application potentially hazardous. However, this is
merely my opinion as an end user. I realise (from our correspondence) that
this opinion may not be universal(!), however, I wanted to leave it here as a
task for completeness sake.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?14363>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/