GNU 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: |
Mohammad Akhlaghi <makhlaghi> |
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.
|
Lee Kelvin <leeskelvin> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Powered by Savane 3.13-758e.
Corresponding source code
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 ;-).