taskGNU Astronomy Utilities - Tasks: task #14362, Automatic pixel value type on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #14362: Automatic pixel value type on image manipulation

Submitter:  Lee Kelvin <leeskelvin>
Submitted:  Wed 08 Feb 2017 07:01:40 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:  Warp Priority:  5 - Normal
Item Group:  Enhancement Status:  None
Privacy:  Public Assigned to:  None
Percent Complete:  0% Open/Closed:  Open
Effort:  0.00

Thu 09 Feb 2017 01:15:50 AM UTC, comment #1: 

This is a great suggestion, thanks Lee.

Indeed the current behavior where the default ImageWarp is in the same type as the input must be modified. For the time being, I am thinking of keeping the double precision floating point as the default output and using a `--type' option to allow the user to set the output type as they like (similar to what is implemented in MakeProfiles, see MakeProfiles options, under the `--type' option). I will do this while correcting it as part of task #14245 (I haven't got to ImageWarp yet!).

But the automatic type determination is a very intriguing feature, it was a great suggestion! Infact it isn't too separate from task #13563 (No need for polygon calculation when simple transformations are needed). Essentially, when we have easy transformations (not just `scale', for example also flip, or rotation by 90 degrees), we don't need to go through all the trouble that ImageWarp goes in now to allow any kind of Homographic transform (calculating the area of each output pixel on an input pixel and etc.). This will make the processing on the simple transformations much more faster. In the process, we can also do automatic type determinations like what you mentioned for the simple transformations.

Based on your suggestion I thought of a more general solution that can apply to any of the programs, not just ImageWarp. For example, I am really impressed by how the `%g' option in C works: it will print a floating point number into the most accurate representation (for example printing `1' for `1.0000000', and the proper number of decimals for floating points). I would be really curious if we could implement something like the `%g' and check the best type for all the pixels in an image, and based on that, choose the best type for the whole image without loosing mathematical precision.

It doesn't just have to be applied to floats, so when the data-set is in integer type, it will also check and for example if none of the values are larger than `255' and `>=0', then use `unsigned char' and so on. We can do all of this with a common option like `--automatictype' so when the user doesn't like the default type of a program's output, they can add this option and get the most appropriate type output. It can also be implemented as an operator in Arithmetic.

But I am too busy to implement the `--automatictype' option right now, so if anyone is interested, please post a comment here and start the work, I would be happy to help ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 08 Feb 2017 07:01:40 PM UTC, original submission:  

ImageWarp currently does all of its internal processing in double precision floating point and then saves the final array in the same type as the input. The output may be optionally coerced to double type using the --doubletype option.

I believe it would be desirable to have the output number type to be dynamically decided upon by default, dependent upon the warpings which have taken place. For example, when scaling a 1x1 pixel image containing the integer '1' into a 2x2 region (--scale=2), the output should automatically be saved to floating point accuracy with '0.25' in each pixel.

Ideally, the automatic output should be the least complex output possible (i.e., producing the smallest output file size) whilst still retaining full mathematical accuracy.

Changing the default behaviour of ImageWarp in this manner would allow for new arguments on the command line such as --originaltype (to force maintain the type of the original input) and also perhaps --singletype, --integertype, --booleantype, in addition to the current --doubletype.

Best,
Lee Kelvin

Lee Kelvin <leeskelvin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by leeskelvin (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code