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

[Mohammad Akhlaghi]

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

This is an interesting suggestion, thank you. It would be great if you could
mention what part of the ImageWarp documentation created this impression?

The solution to this mis-understanding is to think in terms of a continues
grid, not in terms of a discrete pixel space. You are thinking in terms of a
continues space when dealing with rotation, translation, or projection for
example, but for `scale' you want it to be on a discrete space. 

If this feature is implemented for `--scale', the real range of `--scale's
available to the user will not be continues any more, it will be discrete!
This can have many real-life implications: as you know, astronomical datasets
have a very wide range of resolutions that don't easily divide into each
other, if `--scale' is modified as you described, it will be impossible to
warp such images into the same WCS grid (if their pixel sizes are identical).

To make things more clear, I should also explain that when you use the
`--scale' option (or any of the modular transformation options, not the
`--matrix' option). The center of the coordinate space is set at the bottom
left of the first pixel. So it can exactly cover the pixel. If you directly
use the `--matrix' option (`--matrix=0.3333,0,0,0.33333') for raw
transformation, the center of coordinates will be what is defined by the FITS
standard (half a pixel before the first pixel, since the center of the first
pixel is defined to have a value of `1.0' in the FITS standard). Which will
even be more confusing when you are thinking in terms of a discrete pixel
space! 

In ImageWarp, you can also shift the center of coordinates before the scaling
using the `--translate' option (on a continues grid).  So, you see, even the
center isn't fixed, you are free to define ANY kind of transformation!
ImageWarp is defined to be very low level to allow any kind of generic
tranformation for ANY kind of data and science.

I hope the explanations above have clarified the incorrect points below: 

* I must have explained badly in our private communication, I am sorry for
that ;-). ImageWarp DOES NOT "modif[y] the input image such that it is
extended by one extra blank pixel.". ImageWarp works based on the continues
space of COORDINATES, not discrete pixels! So in your example, the last output
pixel (defined by a SCALED COORDINATE GRID), only covers the last two input
pixels. ImageWarp doesn't add a new pixel, there is just nothing for it to
add! It is very important to think in terms of coordinates (a continues grid)
rather than pixels (that are discrete).

* I hope this also explains how this interpretation is wrong: "That is, no
pixel mixing has taken place. Instead, the pixels have been grouped seemingly
irregularly into bins of 3, 3 and 2 pixels, respectively.". Pixel mixing has
indeed taken place: the first output pixel covers 3 input pixels, so their
values have been "mixed" (or added) to generate 3. The same for the last
pixel: as described above, the COORDINATES have scaled, so the last output
pixel covers only two of the input pixels.

What you are suggesting is indeed a desired feature, I don't disagree with
that. So, I suggest that we use another option for that (maybe something like
`--discrete-scale', or `--automatic-scale'), so the user knows that what they
get is NOT necessarily what they asked for. This fact (that the output is NOT
necessarily what the user expected, when looking at the WCS, not pixel
numbers) is very important.

In the case of applications like GIMP this is the default because GIMP only
cares about pixels. In other words, it doesn't have something WCS, to
attribute the pixels to some other reference! For a GIMP user, the mere fact
that two images having the same size is enough for any further processing. 

However, in our science images, depending on the telescope pixel scale (in
units of arcseconds/pixel for example), two images of exactly the same number
of pixels in width and hight can cover vastly different regions of the sky.

As a summary, making this the default behavior would cripple ImageWarp and
make it non-usable in science applications. Adding another option would be a
good solution, so when WCS information doesn't matter and the user only cares
about the number of pixels, they can use that option.

I would be very happy to help anyone interested implement this new option
;-)...

    _______________________________________________________

Reply to this item at:

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

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