General questions regarding high bit depth modes in Photoline

[Herbert123]

Out of curiosity, I have some questions in regards to Photoline's 16bpc mode:

- Photoline works with 16 bpc with integers (not float), correct?

- this covers the full range of 0-65535 of possible values per channel per pixel, correct?

- in Photoshop 16bpc mode is actually a 15bpc mode. The reasoning behind this: 15bpc divides exactly in half (16384), while 16bpc divided by two results in a non-integer: 32767.5 which leads to rounding errors. Photoshop cuts the "non-significant" (as the senior developer behind Photoshop calls it) - losing that one bit of data in the process. At the same time, performance of the calculations is improved (but data is lost).

The mid-point is important for several image processing algorithms. How is this solved in Photoline?

[photoken]

Out of curiosity, I have some questions in regards to Photoline's 16bpc mode:

- Photoline works with 16 bpc with integers (not float), correct?

A partial answer to your question:
http://www.pl32.com/forum3/viewtopic.ph ... int#p34033

[Herbert123]

Thanks, Ken - I am aware that 32bpc is float number based. And as far as I am aware, 16bpc mode in Photoline is integer based, but I am unsure whether it is actual 16bpc, and not "just" 15bpc.

For texture work (3d rendering and 3d game graphics) this can be important to be aware of. Photoshop blatantly cuts the 16th bit - which can be problematic in cases.

I am hoping that one of the brothers can chime in here, and clear things up.

[photoken]

I am hoping that one of the brothers can chime in here, and clear things up.

Yes, they're the only ones who can definitively answer these questions. My reading of the response I quoted was that most of PL's internal calculations are done with 32-bit floating-point precision (regardless of the image bit depth). If my interpretation is wrong, I'll be corrected....

[bkh]

PL has true 16 bit. Shift bit depth right by 12 bits (by didviding by 16 three times), then shift back. You get 16 bands in 16 bit mode, not 8. (Of course, you have to verify that division is by 16 – that's easily done by using a single divide/multiply combination on an 8 bit layer).

Cheers

Burkhard.

[Hoogo]

Afaik PL uses real 16Bit.
But I wonder what algorithms can depend on a "real mid point"? Dividing by 2 looks more like a tricky argument to me, when you add the color "0", you have an odd number of colors, and you can't divide the colors into a brighter and darker half.

[bkh]

The reasoning behind this: 15bpc divides exactly in half (16384), while 16bpc divided by two results in a non-integer: 32767.5 which leads to rounding errors. Photoshop cuts the "non-significant" (as the senior developer behind Photoshop calls it) - losing that one bit of data in the process. At the same time, performance of the calculations is improved (but data is lost).

Sounds like a very cheap excuse. 15 bit (0..32767) doesn't divide in half, either. You'll have to add that extra value. 65534 as pure white would have worked as well, and they have to solve the same problem for 8 bits anyway (or is 8 bits 0..128 in PS?). Retricting the range makes working with overflows a bit easier, though, especially back in times where processors were 16 bit.

Cheers

Burkhard.