Hi Sander,
Fundamentally, I 'think' that the proposed solution 'should' actually work - for any valid FITS file, irrespective of the source (unless we discount some FITS creation software, like Meade's Envisage FITSINT format, which is just plain WRONG !!).
Let's say we are dealing with FITS images that use the ubiquitous 32-bit Float format. Even Envisage can get THAT format right. It downloads 16-bit (integer) data from the CCD - which means an ADU range of 00000 to 65535, and it stores this as 32-bit floating-point data (4 bytes per pixel) in a 'standard' FITS format image. This means that an original ADU value of, say, 12345 would now be stored as 12345.000. Nothing wrong with things so far.
So, when PixInsight comes to 'open' or 'load' the image, the FITS header (correctly) identifies the data as being in 32-bit unsigned floating-point format. It will therefore 'read' the pixel ADU value (correctly) as "12345.000".
It then has a decision to make, based on the <FITS Format Preferences> window parameters. If you simple leave everything set to 'default', then it will test for the condition whereby the data (i.e. ALL the ADU values) is between the Lower Range and Upper Range limits (which default to 0.0 and 1.0). In our case the data WILL be outwith these limits (images written to disk BY PixInsight will have already been re-scaled to the "0.0->1.0" range, so they will NOT fail the range test on re-load) and so they WILL need to be rescaled.
Now, as Juan says, there is no ACTUAL need to rescale to the 0-1 range. The data can remain 'native' (0-65535), and PI will 'rescale on the fly' (or at least that is my understanding), whereby there is a temporary rescale to 0-1, then a process is applied, then the result is returned to the original 0-65535 scale. But I may be completely wrong.
In any case, I can 'live with' a permanent 0-1 rescale - I use the 'on-the-fly- readout rescale to get back to 16-bit Integer values, if I need them. Otherwise I work quite happily in a 0 to 1 world.
What is just NOT working for me is the fact that I simply CANNOT get PixInsight to allow me to define the Upper and Lower Range values - and because I cannot do this, PI seems to rescale the non-conforming image such that "Maximum(T$)" is used for the Upper Range, and thus becomes "1.000" in the opened image.
Which might be OK for images that do actually have ADU values that were fully saturated, all the way up to 65535.
But this is HOPELESS for non-saturated images like Flats, FlatDarks and BiasOffsets.
There simply HAS to be something wrong with the code, if it cannot accept a typed in value of 65535.00000 for the Upper Range parameter.
It is driving me mad, and ruining a perfectly valid attempt to create an image using ONLY the power of PixInsight - from beginning to end

Cheers,