Scaling of FITS on Open

[andyschlei]

I recognize this might be a stupid question, but here I go anyway.

When I open a file I have produced with CCDStack and saves as a 32-bit floating point FITS, I get a dialog: "FITS Floating Point Range Options"

The dialog is as shown here:



I suppose on reflection there might be a bug in CCDStack, because I don't know why any pixel values would be negative, since I have combined a series of images as a sum.  No input pixels should be less then zero, unless they scale the image around zero.

My question is, if I leave the lower and upper ranges at the default values of 0 and 1, am I losing any detail in the image?  Is there a compression of values?  If I am going to 32-bit floating point, why does the image need to be rescaled at all?

Thanks for the help,

--Andy

[Carlos Milovic]

Hi Andy

When working with floating point numbers the scale is interpreted in a different way than with integer numbers. For example, with 8 bits, clearly 0 is black and 255 is white. Floating points, or real numbers, by the other hand, have not such "clearly" defined a range in terms of absolute boundaries, inherent to the number scale. So, as a standardization, we (and many other people) use the normalized range as the base for this representation. This means, 0 is black and 1 is white, while out of range value are simple discarded (clipping) or used for inner calculations, or used to storage non-image data (for example, the second derivative of a image, which is also an image, needs real number to store the data, but 0 is not black and 1 is not white for this kind of data).

Having said that, I'll answer your questions more directly :)

I suppose on reflection there might be a bug in CCDStack, because I don't know why any pixel values would be negative, since I have combined a series of images as a sum. No input pixels should be less then zero, unless they scale the image around zero.

I cannot say for sure... as you say, is quite weird that they got some negative values. It may be that they use internally a range where 0 is middle gray, and black/whites are scaled in some way (for example, +- 3.5). Using 0 as gray may make sense for some processes, or other color spaces, but in my opinion the normalized range is easier to manage and more friendly.

if I leave the lower and upper ranges at the default values of 0 and 1, am I losing any detail in the image?

It will depend on the method you choose to deal with out of range values. As you showed in the capture, right now you are rescaling the values, so no data is loss. The minimum value will be black (0, zero), and the maximum white (1, one), while all the data will be linearly scaled between them.

Is there a compression of values?

Yes, a linear compression. This "may" yield some round off errors, but this is very unlikely with 32 bits, unless you are working with extremely large dinamic range images, in those cases 64 bits are recommended.

If I am going to 32-bit floating point, why does the image need to be rescaled at all?

As I said, going to floating point numbers does not ensure that the scale used has any meaning. You may store a integer image, 8 bits, for example, as floating point numbers with the same values (0 to 255). You'll have 32 bits, floating point values... but scaled in a 8bit dynamic range.
PixInsight uses for floating point samples (and, internally even for integer samples) the normalized range, as described before, for a very good reason: As a module developer, you'll just have to worry designing the processes to work with images in the 0-1 range, and forget all the trouble of handling images with different sampling. This is done internally with objects called templates, and the developer gets a much easier job using them. Now, from the user point of view, he also benefits from this, because he doesn't also need to deal with different ranges for each sampling type. Imagine that you want to apply a curve defined with integer 16bits to an 8bit image... cannot be done directly. Either rescale (automatically), or use just the first 256 values... and, of course, that this will violate our object oriented paradigm in a deeper way than it may be foreseeing at first sight (the processes need to depend of the images, to know how to represent the values on screen).

[Juan Conejero]

Hi Andy,

This is an excellent question.

When a floating point image is being read from a disk file, PixInsight needs to know which pixel values correspond to black and white, respectively. In other words, we need to know the limits of the dynamic range that the image is referred to. This is necessary in order to interpret and represent pixel values correctly.

Unfortunately, the FITS format does not provide a standard way to define these limits. There are no standard header keywords that can tell us which values are to be considered as the minimum and maximum values of the actual dynamic range for a particular image.

I suppose on reflection there might be a bug in CCDStack, because I don't know why any pixel values would be negative, since I have combined a series of images as a sum. No input pixels should be less then zero, unless they scale the image around zero.

This is not a bug. They have the freedom to store a floating point FITS image using the numeric range of their choice; the FITS standard fully guarantees this freedom. A completely different thing, however, is the convenience of doing this. We do think that a standardization of floating point pixel values is a must, and we try to enforce it as long as we can. But this is just our opinion.

As you probably know, PixInsight uses what we call the normalized real range to store and represent floating point pixel values. This is just the [0,1] range, where 0 corresponds to black (no signal) and 1 corresponds to white (full signal). All floating point images written by PixInsight (currently TIFF and FITS images formats) are always represented and stored in the normalized range.

Unfortunately, other applications usually store floating point images using arbitrary ranges (and sometimes quite odd ones, as you can verify). What happens when we try to read a floating point image that stores pixel values outside the normalized range? How can we know how to interpret existing pixel values? Quick answer: we cannot. Even worse: we have no way to know in advance the range that has been used to represent pixel values stored in any floating point FITS file.

Our solution to this problem is simple: let the user tell us about the ranges used in every floating point FITS file that doesn't fit the normalized range. You have several options that you can tweak to make things easier. Do the following:

- Open the Format Explorer Window

- Double click the FITS item on the left panel

- On the FITS Format Preferences window, you have:

* Default Floating Point Input Range. This is the effective range that will be considered for FITS files whose pixels fit inside this range. In other words, the minimum and maximum values here are taken as black and white, respectively, to read FITS images. By default, this is the [0,1] range. I recommend you to leave this unchanged.

* Floating Point Out of Range Policy. By default, this is set to "ask on out-of-range values". If you know that you'll be working with nonstandard FITS files all the time, it can be better to change this to "normalize to the default input range". In this way you'll receive no "Range Options" dialogs, and you'll lose no data at all, since the minimum value in the file will be taken as black, and the maximum as white, respectively.

My question is, if I leave the lower and upper ranges at the default values of 0 and 1, am I losing any detail in the image? Is there a compression of values? If I am going to 32-bit floating point, why does the image need to be rescaled at all?

You'll lose no data at all, as long as you leave the "If out of range" option to its default "Rescale image to the specified range" setting.

With the default [0,1] input range, this is what will be calculated for each pixel:

v' = (v - min)/(max - min)

where v is the read pixel value, v' is the final value used by PixInsight, and min, max are, respectively, the minimum and maximum pixel values in the image (the extreme pixel values shown on the FITS Floating Point Range Options dialog).

Two conclusions:

- If possible, try to store your images in 32-bit integer format, instead of 32-bit floating point. With integer pixel values, you'll have no range problems, and the 32-bit integer format is much more accurate than 32-bit floating point (2^32 discrete values instead of about 10^7 values). PixInsight can read and write 32-bit integer FITS and TIFF files. I know that many other applications can't, though...

- If possible, don't use the FITS format to communicate image data between different applications. Unfortunately, there are popular applications and camera makers out there that make really wrong use of the FITS format to store almost anything in very odd ways. Of course, I'm not speaking of CCDStack, which does follow the FITS standard well, AFAIK.

Hope this will help more than confuse :roll:

[andyschlei]

Juan and Carlos,

Thank you for two excellent and well explained replies.  I think this clears it up for me.  As long as nothing is lost in the re-scaling, then I won't worry about it.

One comment on Juan's recommendations:

- If possible, try to store your images in 32-bit integer format, instead of 32-bit floating point. With integer pixel values, you'll have no range problems, and the 32-bit integer format is much more accurate than 32-bit floating point (2^32 discrete values instead of about 10^7 values). PixInsight can read and write 32-bit integer FITS and TIFF files. I know that many other applications can't, though...

- If possible, don't use the FITS format to communicate image data between different applications. Unfortunately, there are popular applications and camera makers out there that make really wrong use of the FITS format to store almost anything in very odd ways. Of course, I'm not speaking of CCDStack, which does follow the FITS standard well, AFAIK.

In a quick test I found that an integer image took two passes of histogram (no clipping, of course) to pull into visibility, where the floating point version came up in one pass.   I assume that this is because the floating point version gets somewhat stretched when the values are normalized into the [0,1] range.

On inter-application file transfer:  I get 16 bit integer FITS from my ST-10 and Maxim DL at capture time.  I then stay in FITS as I process and stack the images in Maxim DL and CCD stack before I get to PixInsight.  I figure all of these are compliant with the FITS standard.  But I'll limit it to that.

Thanks again,

--Andy

[Carlos Milovic]

Hi Andy

Not stretched, but rescaled (by stretching it is assumed that a non linear transform were applied, like the gamma function, midtones balance, ddp, or whichever). Rescaling, by the other hand, implies that the boundaries of the dynamic range are moved, and data is compressed or expanded linearly to use all the "meaningful range".

This said, when you rescale the floating point sample, even when numerically you are comprissing the values, from other point of view you expand it to cover all the possible grayscale (color) values. The integer 32bits image, on the other hand, has unused dynamic range space at both sides, wich may explain why you needed an extra pass. I think that, if you rescale the 32bits integer image (there is a process called Rescale), you'll get the same results as in the adjustment done for the floating point image. If this does not happens, there is something really odd here.

[andyschlei]

Carlos,

Thanks for the quick response.

Not stretched, but rescaled (by stretching it is assumed that a non linear transform were applied, like the gamma function, midtones balance, ddp, or whichever). Rescaling, by the other hand, implies that the boundaries of the dynamic range are moved, and data is compressed or expanded linearly to use all the "meaningful range".

That is what I meant.  I was imprecise with my terminology.  :oops:

This said, when you rescale the floating point sample, even when numerically you are comprissing the values, from other point of view you expand it to cover all the possible grayscale (color) values. The integer 32bits image, on the other hand, has unused dynamic range space at both sides, wich may explain why you needed an extra pass. I think that, if you rescale the 32bits integer image (there is a process called Rescale), you'll get the same results as in the adjustment done for the floating point image. If this does not happens, there is something really odd here.

I used the rescale function and the image looks and behaved exactly like the floating point image.  Thanks for pointing that function out, I'll add that to my processing technique.

This whole learning process for me serves as yet another example of what a great tool PixInsight is.  It is making me understand the underlying process rather than blindly accept what the software is doing.

Clear skies,

--Andy

[andyschlei]

One other question.

Am I still better off using 32 bit integer then 32 bit floating point?  Even if I need to rescale the integer image before processing?

I tried using 16 bit integer and I could tell that I lost dynamic range in the image.

I just want to be sure.

Thanks,

--Andy

[Carlos Milovic]

IMHO, for common astronomical images, 32bits floating point is enough. Maybe you'll need the 32bits integer larger dynamic range if you are merging images with very different exposure times, linearly... let's say, for a rough example, 10 min exposures with 10 seconds ones (and some exposure times between them). So far, in my experience with my 300D and HDR images, I have not reached this limit yet (or, at least, not visually detectable). Vicent once made a very high HDR image that needed 64bits to store all the data, that is shown in a tutorial somewhere


Well, I would say that as far as you are working with 32 bits, regardless if it is integer or floating point, you'll be safe for almost every situation ( If anybody wants to contradict me, is highly welcome )

[Juan Conejero]

What Carlos has said is true: with 32-bits per sample, no matter floating point or integer, you have enough accuracy for normal or even moderately complex processing tasks.

However, since the PixInsight platform supports the 32-bit integer pixel format in a completely transparent way, I generally tend to favor its use. Obviously, an image occupies the same amount of disk and RAM space in any 32-bit format, floating point or integer.

There is indeed a difference in performance: most internal operations will run faster with floating point data. This is because all intermediate calculations are performed on 64-bit floating point temporary data arrays for 32-bit integer images. This is necessary to preserve the whole numeric range of 2^32 discrete values. This can be expensive in terms of memory consumption, and the required conversions are moderately slow.

But with today's processors this isn't a practical problem, unless one has to process lots of large images applying very intensive procedures. And in such cases, the extended numerical range provided by 32-bit integers is usually desirable, anyway. The high-performance alternative is using 64-bit floating point images all the time, but at twice the cost in RAM

The high-dynamic range experiment that Carlos mentioned is in this PDF document (24 MB):

http://pixinsight.com/eccai_2006/pixinsight_eccai_2006.pdf

See the 64-bit High Dynamic Range Experiment on page 9 of this document.

My advice is:

* Never use the 8-bit integer format for anything but to generate bitmaps (PNG or JPG images for example).

* As far as possible, avoid 16-bit images for processing, except for relatively simple tasks.

* Use a 32-bit format for all serious processing work. The 32-bit integer format is the best option to implement very complex procedures, due to its numeric range of 2^32 discrete sample values. With 32-bit floating point, you get about 10^7 discrete sample values, or about 10^6 after complex tasks, due to roundoff errors.

* The 64-bit floating point format is only necessary to deal with extremely large dynamic ranges and very complex procedures.