help please - understanding sample formats

[mikeoday]

Hi

Please forgive the very possibly stupid questions but I cannot figure out what is going on...

I have been trying to multiply the red and blue channels by the appropriate factors to balance the green channel in a raw DSLR image.  However, it seems that  Pixinsight is clipping the highlights when I multiply the red channel in my 32bit floating point image by 2 using PixelMath.

I did a quick experiment and I don't understand the results ...

That is:

create a new 8 bit integer image with pixel values 128
convert to 32 bit unsigned integer format (pixels should be unchanged at 128)
multiply the image by 1,000,000 using PixelMath (pixels should have value 128,000,000 with is still way less than the maximum value of 2^32-1)
divide by 1,000,000, and the pixels should be back to 128

The pixels should have value 128 but they don't, they are zero?

Can anyone please explain what is going on?

thanks
Mike

[Juan Conejero]

Hi Mike,

convert to 32 bit unsigned integer format (pixels should be unchanged at 128)

No, it doesn't work this way. In 8-bit unsigned integer format, the representable range of the image is [0,2⁸-1], or [0,255]. In 32-bit unsigned integer format, it is [0,2³²-1]. Therefore, after you perform the conversion, the 32-bit pixel value is:

128/255 * (2³²-1) = 2155905152

Now the rest of your results explain by themselves.

PixInsight can work with five pixel sample formats (8-bit, 16-bit and 32-bit unsigned integers, plus 32-bit and 64-bit floating point) transparently. Transparently here means that the pixel data are stored in their respective formats in memory (for example, for an 8-bit image, each pixel of a color RGB image occupies 24 bytes), but you can see and work with them as virtual pixels in any arbitrary format of your choice. All image processing tools and algorithms can work with any of the five formats, also transparently.

The normalized real range [0,1], which is used pervasively on the PixInsight platform, is an abstract range that allows you to work uniformly with any pixel sample format, current and future. For example, in your test case:

128/255 = 2155905152/(2³²-1) = 0.5019607843137255

In the normalized real range, 0 is black and 1 is white, irrespective of the actual pixel sample format of the image. Floating point images are internally stored and manipulated in this range in PixInsight, which has important algorithmic advantages.

Unfortunately, many users still don't understand this and persist using pixel readouts in native pixel sample formats. This is a serious error in PixInsight. From a purely practical and logical perspective, once you get accustomed to the fact that .37 is just a 37% of the black-white range, you'll find it much easier to work this way than thinking in terms of 94.35, 24247.95, or 1589137899.15.

[mikeoday]

Thank you Juan for the detailed reply.  I think I understand now.

But, how then does one manipulate multiple images without clipping?  For example, if I have a DSLR RAW image that is "green" and needs to be balanced by multiplying the red channel by 2, blue by 1.4 and green by 1 but the highlights in the red and blue channels are already nearly saturated then the multiplication will clip the red and blue channels.

Ok, so am I right in thinking that instead one should always ensure that the maximum values stays less than 1 in the 0 to 1 range?  So, in the example above, the balance is achieved by Red x 1,  Green x 0.5  and Blue x 0.7?

And, if you add 2 nearly saturated images together they will always clip and instead one should divide them by 2 before adding them together?

Cheers
Mike

[pfile]

the "rescale" option in PixelMath should prevent saturation, but you can also divide your factors by the largest multiplier to come up with fractional factors as you've discovered.

rob

[mikeoday]

Thanks Rob.