Photoshop 2015.5 32 Bit --- What Exactly Happens

[Guest]

Hi There,

perhaps someone could be so kind as to explain to me what exactly happens when switching Photoshop into 32 Bit mode...

based on following example...

1) Create a 10x10 - 8bit Image in Photoshop an set the background to 128, 128,128 for the color components.

2) Hit Create

3) Swap mode to 32 bits...

Behind the scenes ALL values are undergoing the following ->

(128/255)^2.2 = 0.2195197181

Where I would expect the following to happen...

(128/255) = 0.5019607843;

The image is visually identical --- HOWEVER --- only until one turns on proofing and set that to sRGB.

That means that while the user believes his values are 'Intact' - in fact they are being subject to a 2.2 gamma.

WHY and where exactly in the documentation can I read about this ?

Currently I would not feel comfortable making out plug-in support 32 bit in Photoshop due to the lack of information on the subject.

Is this a bug or is the behavior expected ?

Thanks for any detailed advice on this topic

-- Dieter

BTW - This forum editing capabilities support Undo but NOT Redo....

[Tom Ruark]

From a colleague: 32 bit mode is always linear gamma. sRGB has a 2.2 gamma. The math is the conversion to linear space. Linear space gives more accurate results for blending and many other  operations, but because it’s not perceptually uniform (our eyes respond logarithmically to light energy) a gamma encode space more effectively uses the limited encoding resolution of an 8 bit representation. An 8 bit linear encoding would result in banding in some areas and wasting lots of encoding values on differences that can’t be seen in others. 32 bit representations have such tiny steps between values that banding is never an issue, so we (and pretty much everybody else) opts for the advantages of a linear encoding.

Some 16 bit profiles specify this too: Lightroom internally uses a gamma 1.0 version of  ProPhotoRGB (a wide gamut space) for a similar reason.

[Guest]

Hi Tom,

thanks for taking the time to reply.

Are you using the sRGB formula or a standard 2.2 Gamma to linearize...

Latter is 'Simpler' but not Mathematically correct. We just need to know which one is being used.

I suspect a 2.2 Simple Gamma due to discrepancies in results coming off FilterRecord Pointer Dereference after running tests.

Just would like to know....

Just a thought...

1) If one opens an 8 bit image and turns on Proof Color (i.e. sRGB)

2) Converts to 32 Bit Color Mode.

3) There is ZERO Visual Difference.

Reason being that Photohop automatically turns off Proof Color. That would lead any user not 100% savvy to believe that his image never underwent a linearization of its Gamma where intact it did...

Turning on Proof Color makes it clear that the image has been indeed linearized.

Is this a bug or a wanted behavior ?

Thanks again for your time

[Royi A]

Tom Ruark​, When a Plug In pulls data in 8 / 16 Bit, what does he gets?

The data encoded using 2.2 Gamma or the data is going through inverse Gamma before that?

[Tom Ruark]

When you ask for data, you always get the current numbers — the data in the current document profile. If it’s a profile with a gamma of 2.2, you get gamma-encoded data. We don’t transform the data before handing it over.