Is the LAB mode suitable for every photo?

[Guest]

Hi folks,

I was wondering if every image can be edited in LAB mode? Or are there situations, where the "good old" RGB mode is more appropriate?

[Mylenium]

Not sure what you mean. It all depends on the specific operations. There is no general "A is better than B" here. you need to be a lot more specific about what you are actually doing and why you think the Lab mode would be superior or preferable to RGB or whatever.

Mylenium

[c.pfaffenbichler]

I was wondering if every image can be edited in LAB mode?

Why would you want to do that?

Anyway, working in Lab in 8bit would not be a good idea.

Or are there situations, where the "good old" RGB mode is more appropriate?

Working in RGB Is a perfectly valid option for editing photographic images.

[G_Hoffmann]

c.pfaffenbichler  schrieb

Anyway, working in Lab in 8bit would not be a good idea.

Dear Christian, dear Dag,

practically working in Lab in 8bit (Lab-8) seems to be not so bad:

The first edition of Dan Margulis book "Photoshop LAB Color" is entirely based

on PSD Lab-8 data, at least this is my impression after checking some examples

on the CD.    

My test:

The first image IM1 is an sRGB image of a PDF page (a rather complex printer test

page) with 288ppi, then downsampled for 72ppi, then saved as JPEG (Q=9).

The second image Im2 is an sRGB image of the same PDF page with 288ppi,

then converted to Lab and saved, then reloaded, converted to sRGB, then

downsampled for 72 ppi, then saved as JPEG (Q=9).

The third image, if shown (it is in background), is the result of the calculation for

Im3 = 127 + 2*(Im1-Im2) for the gray channel (numbers 0..255), actually a uniform

area, but the histogram has a small peak with standard deviation 0.33.

Perhaps is my test too weak or even wrong? Then we have still Dan Margulis' book...

These arguments are in my opinion saying, that it is not generally wrong to work

in Lab-8.

Best regards --Gernot Hoffmann

[Norman Sanders]

G.Hoffmann​​. In strong support of your conclusion I direct you to pages listed in the index under "Bit Depth" in the First Edition of "Photoshop Lab Color."

Those who follow Dan's writings are aware that, before making a pronouncement, he does extensive testing and also asks his readers to submit work to prove or disprove his conclusions.

To quote from the book:

"In the past three years, about a dozen people. including me, have made serious efforts to find anything to support the proposition that 16-bit might be better under any circumstances. By that, I mean any unretouched color photograph that might possibly be used in the real world and any sequence of attempts to improve the image, however farfetched, where editing in 16-bit creates a better result than 8-bit images. Images have been tortured beyond belief. Nobody has found any quality gain at all."

As he reminds us elsewhere in the book:
"16 bits per channel, which gives us a theoretical possibility of of 65,536 levels of gray, (are) still reported to us on the same 0-255 scale."

More support for his conclusions also appeared at his Yahoo "Photoshop Color Theory Newsgroup" column in 2004. It is too long to include here, but it is available from me on request.

Finally, for those who want to string me up for what you feel is heresy, remember that I am only the messenger. Take It up with Dan.

[D Fosse]

norman.sanders  wrote

As he reminds us elsewhere in the book:

"16 bits per channel, which gives us a theoretical possibility of of 65,536 levels of gray, (are) still reported to us on the same 0-255 scale."

Well, that's just the readout, not the underlying data. It's the same for RGB and Lab. If you want to, you can set the info panel to give you the actual 16 bit numbers.

[Eugenio.NYC]

Great conversation,

I printed images in 16bits workflow using the sony a7r3 and the Canon pro1000 and in my opinion, the result is way much better than if I print with 8bits workflow. For me, that is a good way to see differences.

Regards

E

[D Fosse]

Here's a repeated soft brush in Lab 8 bits vs. Lab 16 bits.

I think this settles the issue. Yes, it's exaggerated, but we're trying to make a point here, right? It's like jpeg. You may not see the damage on first save, but we all agree it should be avoided for full data integrity.

[Norman Sanders]

Point made.

I think that Dan was careful to qualify his conclusion this way (as included in the quote above):

"...By that, I mean any unretouched color photograph that might possibly be used in the real world..."

He based his 8 vs 16 and other conclusions stated in his books on that stipulation... real world color photographs.

I think he truly would be interested in hearing from you at his Yahoo site.  

In the spirit of full disclosure: Similarly, years ago, when comparing lenses, I preferred to skip shooting charts to measure lens aberration variables and opted for taking identical pairs of photographs indoors and out, where the only variable in each comparison of results was the lens used. I hope that doesn't make me a bad person.

[D Fosse]

norman.sanders  wrote

I hope that doesn't make me a bad person.

No, it doesn't make you a bad person   We've all used that exact argument - depending on what point we're trying to prove that day. For instance, I'm very fond of referring to real world photographs when the discussion is about 10 bit capable displays (no, it doesn't really matter; you can't tell the difference. I have three of them).

I think the sensible way to treat this is equivalent to how we treat resaving of jpegs. Generally to be avoided on principle, but sometimes, what the heck. Who's gonna know...

[Stephen_A_Marsh]

That would be classed as a computer generated image, not a photograph. Dan has stated that for synthetic images a higher bit depth has advantages.

[c.pfaffenbichler]

"In the past three years, about a dozen people. including me, have made serious efforts to find anything to support the proposition that 16-bit might be better under any circumstances. By that, I mean any unretouched color photograph that might possibly be used in the real world and any sequence of attempts to improve the image, however farfetched, where editing in 16-bit creates a better result than 8-bit images. Images have been tortured beyond belief. Nobody has found any quality gain at all."

In my experience there are image manipulations that customers may request that will cause problems like banding when attempted in 8bit, for example making a black shirt (or other object) appear white (or the other way round).

[c.pfaffenbichler]

These arguments are in my opinion saying, that it is not generally wrong to work

in Lab-8.

I did not say »wrong« but just try to convert an 8bit version of an original 16bit sRGB image to Lab then back to sRGB and overlay it with the original with Blend Mode Difference.

Then do the same for the original 16bit sRGB image.

The Histogram should demonstrate that the change is bigger in the 8bit version.

So why accept more unintended changes than necessary?

[D Fosse]

You'll discover that each has its own, distinctive advantages and disadvantages.

The main difference is that in Lab, the color component is totally divorced and independent from the luminance component. This is sometimes a good thing, sometimes just complicating everything.

There are some operations where I always convert to Lab, such as desaturating, because it maintains the inherent lightness of, say, a bright yellow. For other things like correcting color casts Lab is unpredictable and clumsy. 

Because Lab is such a huge color space, like ProPhoto, you absolutely need to be in 16 bit depth.

[c.pfaffenbichler]

Because Lab is such a huge color space, like ProPhoto, you absolutely need to be in 16 bit depth.

Indeed.

Pretty much any relevant RGB Space is considerably smaller and converting an Lab-image into it would therefore mean that a lot of information could get wasted.

[Eugenio.NYC]

Check the Dan Margulis book, a good reference about LAB in my opinion

[Norman Sanders · Accepted solution]

The question you asked deserves a complete answer, one that describes the advantages, limitations and myths regarding this unique color mode. The books by Dan Margulis that are devoted to the subject run about 400 pages. It is not light reading but very rewarding. I recommend that you start with the first edition of "Photoshop LAB Color". It is the one with the cover shown on the left. You will learn when Lab is the most appropriate mode for achieving a desired result and when it offers little benefit. I can promise you an education in Curves, and awareness of Lab's valuable source for the basis of masks that can then be applied in Lab, RGB or CMYK.

On a personal note, some years ago I invited Dan to present a lecture to my college students in NewYork It was unforgettable. I can't recall any other time when, at the conclusion of a guest lecturer's presentation, the students gave a resounding standing ovation.  In my opinion, these two editions (I use both) and  Dan's "Professional Photoshop" provide an indispensable education, especially if you intend to prepare your work for print.    

[Guest]

Hi Norman,

great answer. Thank you for your help.

[rayek.elfin]

But then, if we are talking about data integrity, for certain tasks we ought to be careful when using Photoshop's 16bit mode, which can handle 0-32,768 values, and not the full 0-65,535 16bit range of data for images that make use of the full range of 16bit (stellar photography, HDR, medical imagery, 3d depth data, 3d dynamic range rendering and digital painting, etc.). Those data ranges will be reduced to 32,768 values when opened in Photoshop's 16bpc mode, losing half the data.

Anyway, for the bulk of photography work it doesn't matter, since most photos are at most 12bpc, if I remember correctly. Still, it might have negative consequences if not kept in the back of one's mind for certain jobs, including HDR photo stacking.

My question would be: since the point was made in this discussion that LAB works best with higher dynamic ranges, how does the 0-32,768 range in Photoshop affect working in LAB mode? Does it matter? Would a full 16bpc mode with a 0-65,535 value range yield potentially better results? Or is the point moot, because only in edge cases would it have a noticeable effect, if at all?

How much more effective or controllable are LAB moves in a full 16bpc range?

I am genuinely curious.

[D Fosse]

Who said there were any problems in Lab 16 bits, Rayek? Read again. We said there were problems in Lab 8 bits. Nobody said there were problems in Lab 16 bits, or 15+1.

This time I want you to show us how and why Photoshop's 0-32768 range destroys data, in a way that could be prevented with a 0-65535 range. I want to see actual examples from the real world.

Show, don't tell.

[rayek.elfin]

Here you go.

Here is the original 16bit full range 0-65535 HDR image. The centre of the sun is around 63455, and the darkest shadow around 50.

To test if Photoshop destroys data, I adjusted the gamma of the image in PhotoLine.

I then flattened this image and saved it as a new full range 16bit PNG file.

In PhotoLine I reversed the gamma again:

In Photoshop I opened the same image, and reversed the gamma once more:

Result: in PhotoLine the sun's data remains unchanged. In Photoshop it blows out. The highest value possible is 32678, and indeed the center of the sun is exactly that value. But it also lost details, and the halo is gone. Photoshop's conversion to 0-32768 from a higher range of 0-65335 values seems to ignore the higher dynamic range values and maps the colour range in such a way that the higher range is capped.

Which means Photoshop destroyed the high-range values, and the result is very visible.

Is that enough proof for you?

Now, back to my original question: how does this affect LAB moves? I am just genuinely curious if someone knows, because I have no idea myself.  I am not trying to diss Photoshop here. Photoshop's 16bit mode is what it is. If LAB works best with high colour ranges, is it theoretically possible that LAB moves would be affected by this, compared to an application that does work with the full 16 bit range? Similar to the 8bit versus 16bit?

[D Fosse]

OK, thank you Rayek. That's all I asked for.

rayek.elfin  wrote

I am not trying to diss Photoshop here.

Yes you are, and you have been for years. You've had one singular message in all your postings here: Photoshop is broken. Oh, and BTW, here's a competing product that is way better. Can you really blame us for getting a bit on edge? I don't think so.

But anyway, if this means we can agree on substantiating our posts with good visual examples, instead of just making assumptions and claims, that's good.

BTW the screenshots are untagged, so if this whole exercise has been done without color management, it's of no value. The area immediately around the sun differs by no less than 10 8 bit values. So something else is going on here. That can't be explained by 32768 vs 65335.

[rayek.elfin]

@Dfosse I am sorry you feel that way about my posts. I don't think Photoshop is broken. I do think the software is hampered in a number of areas by a legacy core code which, in my opinion, is in dire need of an update.

The pseudo 16bpc mode is a prime example (the most important one I feel). And I haven't been the only one complaining about the silent 15bit conversion by Photoshop throughout the years. Don't you feel it is a bit silly that for this test I had to resort to another image editor to prepare a full range 16bpc version?

You mention all of my posts on the Photoshop forum are overly critical of Photoshop. I'll do a tally later this week to see if this is so, and if an inordinate percentage are (even though they may be justified in their criticism), I'll have to reconsider my presence on these forums.

As for this test, it was done with a colour managed workflow, but because I create assets for games, my default export settings remove the colour profiles. That said, I had Photoshop installed on a different machine, so to be sure this is not a result of that, I'll test the same thing again tomorrow at work, where I have access to iMac Pros. And I will send you the actual 16bpc original for you to check tomorrow evening after work.

c.pfaffenbichler​ The difference method will probably be helpful to check what the difference is when making the same LAB move in 16pbc versus 15bpc. I'll check that tomorrow myself as well. Thanks!

[c.pfaffenbichler]

And I haven't been the only one complaining about the silent 15bit conversion by Photoshop throughout the years.

To nitpick: It is not 15bit, it is 15bit + 1 value, so it is impossible to be expressed in plain 15bit but the 16th bit is not being used to its »full extent«.

[rayek.elfin]

c.pfaffenbichler  wrote

To nitpick: It is not 15bit, it is 15bit + 1 value, so it is impossible to be expressed in plain 15bit but the 16th bit is not being used to its »full extent«.

Yes, true, I am aware of that.

I recall a conversation between Chris Cox and a number of users asking about this (others here probably as well?). Basically, when he implemented the 16bpc mode in Photoshop he decided to go with 15bit + 1 value to be able to simplify the math so that the code could use simpler values for calculations, speeding it up. Reading between the lines, his thinking at the time was that computers were pretty slow, memory was limited on most user's machines, and he implemented the 0-32768 range instead of 0-65335 to be able to divide by 2, and (my interpretation) the team at the time probably felt that a proper 16bpc mode would be overkill anyway in practical use. So, two birds in one: easier to code for, and speedy performance at the time with lower memory overheads.

It made total sense, what?, twenty years ago, of course. My assumption is that they never expected the whole HDR and rendered graphics business to happen (how could they? Totally understandable!). I also think this code affects many parts of Photoshop core code, making it more difficult for the current dev team to replace with a full range 16bpc one. I can't imagine the PS team not wanting to improve this part of Photoshop, if it wouldn't be a time-consuming and complex job to refactor this code.

Of course, these are assumptions on my part, and I may be completely wrong here.

Logging off...