gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lee Kelvin
Subject: [gnuastro-devel] [task #14363] Change the default behaviour of --scale in ImageWarp
Date: Wed, 8 Feb 2017 15:16:05 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

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

                 Summary: Change the default behaviour of --scale in ImageWarp
                 Project: GNU Astronomy Utilities
            Submitted by: leeskelvin
            Submitted on: Wed 08 Feb 2017 08:16:03 PM UTC
         Should Start On: Wed 08 Feb 2017 12:00:00 AM UTC
   Should be Finished on: Wed 08 Feb 2017 12:00:00 AM UTC
                Category: ImageWarp
                Priority: 5 - Normal
              Item Group: Enhancement
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

The current method by which image scaling takes place in ImageWarp may be
confusing to many users. The value taken from --scale should be made flexible
in order to perform scalings which are non-trivial.

By way of example, consider an image of dimension 8x1 pixels, i.e., 8 pixels
in a row. For the sake of explanation, imagine that each pixel has a value of
1. I now perform the command:


astimgwarp --scale=0.33333,1 input.fits


As is obvious, scaling 8 pixels by 1/3 on an axis is non-trivial, as 8 does
not divide into 3 perfectly. In this situation, ImageWarp must make a decision
on how to handle this request. 

Having read through the relevant sections of the ImageWarp manual, I would
have expected ImageWarp to employ its pixel mixing routines to split those 8
pixels into 3 regions of equal area, and generate three output pixels. In the
case whereby our 8 hypothetical input pixels each have a value of 1, I would
therefore have expected the three output pixels to have a value of 8/3 each
(~2.666).

However, if you run the command above on the hypothetical 8x1 image, the
output image produced by ImageWarp produces pixels with values of [3,3,2].
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.

In order to further explain the differences between expected and actual
outputs, the attached image shows this in graphical form. 

I found this behaviour to be most confusing. On discussing this matter with
Mohammad he informs me that in order to perform the command above ImageWarp
modifies the input image such that it is extended by one extra blank pixel.
That is, effectively the input image dimension is internally assumed to have
dimensions of 9x1 prior to performing any image scaling.

I do not believe that the current behaviour ImageWarp exhibits in this
situation is either desirable nor obvious. It seems to me that the current
mode of operation effectively performs a redefinition of the input image,
changing the dimensions of the image to suit the scaling. I believe that any
redefinition of input imaging is not what the user would expect, and may even
be dangerous to the integrity of a dataset.

In order to see how other programs deal with such a situation, I turned to the
image manipulation software GIMP. When asking GIMP to scale an 8x1 pixel image
by a factor of 0.333, the scale factor is automatically changed to 0.375
(3/8). That is, the scale value is automatically rounded to the nearest
sensible value. In essence, this is what I believe ImageWarp should do also. 

TL;DR: In summary, when presented with a non-trivial image scaling request,
ImageWarp has two options: 1) to modify the input image such that it better
suits the requested scaling value, or 2) to modify the requested scaling value
such that it maps directly onto an output pixel map. The current mode of
operation is 1), which I believe to be unexpected and potentially dangerous. I
advocate a change to option 2), in line with many other contemporary image
manipulation software.

Best, 
Lee Kelvin




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 08 Feb 2017 08:16:03 PM UTC  Name: pixmix.png  Size: 16kB   By:
leeskelvin

<http://savannah.gnu.org/task/download.php?file_id=39705>

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]