This topic has been discussed
ad nauseam on this forum. So let's disassemble this fallacy once more.
The main problem is that while the world (everyone except PixInsight) reads fits floating point data as absolute values, PixInsight interpret them as relative values (ie relative to white point and black point).
PixInsight is an
image processing application, hence it needs to know the black and white points of an image in order to correctly represent and handle its pixel data.
Reading "absolute values", as you describe it, can be enough for a
data array manipulation application, although this can be questionable. An
image processing application, however, definitely needs to work with pixel sample values relative to the numerical ranges where the images are being represented. So perhaps the problem is with this "world except PixInsight" that you mention.
This is really a basic point; if it has to be explained or justified further, then I would recommend some bibliography on basic image processing topics.
So when the boundaries are not established like in fixed point formats the internal scaling procedure of PixInsight fails, and we get issues as the stated by Bob Franke.
No, the internal scaling procedures of PixInsight don't fail (modulo bugs, of course). The issues you are referring to are mainly due to lack of knowledge about PixInsight. They are also caused, IMHO, by wrong preconceived ideas about PixInsight and the superiority complex that plagues part of the astrophotography community, but this is a different story.
PixInsight invented a work around to solve the read issue, forcing the user to introduce a range in format explorer, and so allowing a correct scaling of the data
Again, I disagree. PixInsight does not "force" anything. On the contrary, our implementations of the FITS and TIFF formats are flexible enough to allow you to import virtually any image in PixInsight, in any numeric range, generated by virtually any application.
Instead of hard coding numeric ranges in FITS or TIFF preferences, you can use format hints to define them locally in tools such as ImageCalibration, ImageIntegration, StarAlignment, etc. Format hints are even more flexible and adaptable.
Imagine the mess having for each image to manipulate the read range in order to get them read ok, imagine if you have a script reading and writing images....
The mess certainly exists and is being caused by deficiencies in the FITS format specification, which we have discussed uncountable times on this forum, along with inconsistent and/or undocumented implementations in other applications. These deficiencies generate interoperability problems, which are more "visible" in PixInsight simply because PixInsight is more complex and imposes more strict constraints, as described above.
One of the wrong preconceived ideas about PixInsight that we see more often is that it only works in the [0,1] range internally. This is simply not true. A real or complex floating point image can use an arbitrary range in PixInsight. A script or module can read floating point FITS images in memory exactly as they are stored in the source files without any transformation. So this problem simply does not exist from a programming perspective, especially considering that
all of the code involved is open-source.
There is also the write issue: all fits floating point data is written by PixInsight in 0-1 range (absolute) so, if you read any image in PixInsight and then write it to a floating point fits file, the data is altered.
Numerical values are not sacred tokens; they are useful only if they can be meaningfully interpreted and manipulated, and representing them in different ranges and scales does not change their meaning, as long as the applied representations are documented so that everybody can use them correctly.
The data are not altered because rescaling to a different range is a linear operation. Floating point pixel samples are simply represented relative to a particular real range, which has been documented. Other applications use different ranges to store floating point and integer data, which in some cases remain undocumented. However, you don't say that they are altering the data, why?
All floating point fits format images written by PixInsight are read as almost pure black in other programs. I tested this with images which where stretched and ready for printing and got almost black results in other programs.
This happens because, contrarily to PixInsight, these other programs are unable to interpret floating point pixel data relative to an arbitrary numeric range. We publicize and document the numeric ranges that we use consistently, while others don't. In addition, our FITS format support module is an open-source product, whose source code can be studied, analyzed and contributed:
https://github.com/PixInsight/PCL/tree/master/src/modules/file-formatsFinally, we have started the XISF initiative to create an open-source, free, efficient and interoperable format, where all of these problems cannot happen by design.
Other programs are simply not flexible enough, so in this case the problem is theirs, not ours.
