Topics

Retrieving impossible colour from Lab


John Phillips
 

Hi, I am curious about what happens to out of gamut colours during an Lab - to RGB conversion - where do they go and is there a way to keep this information? 

As I understand it, when a L*a*b image is converted to RGB, the colour values are clamped to fit into the 255 range, leaving legal representations of colours. 

I wondered if it is theoretically possible to conduct this conversion and store on file only the data which is out of gamut, without the proxy colours? 

Mr Margulis' work has inspired me for nearly 2 decades, I am an artist working on an experimental project and would like to produce files which are entirely out of gamut, with nothing visible to SRGB. Even if this means producing a blank image. 

Thank you


Rex Waygood
 

If I understand correctly you have an image/graphic etc in Lab and you want to remove colours that are in Gamut for sRGB leaving the OoG colours available to you in some form.

Interesting idea. 

Any Lab to sRGB conversion you do will complicate your requirement due to Intent where OoG colours will be put in Gamut using one of the methods allowed. (The sRGB that we currently use does not support Perceptual intent. I think there is a Beta version that does.)
I don't know the answer to your question but I would start my investigation using ColorThink Pro which is a colour tool.
It has a tool called a worksheet where when you load an image you can get an Excel spreadsheet of a sample of the colours in your image. The sample size can be very big! I did 10,000 samples of each of 40 of my images producing 400,000 samples which I then "played" with mathematically. You can get the spreadsheet in LCH mode and that is much easier to use to do what you want.
I would then sample the image and the sRGB gamut edge by slices in L and segments in H and basically devise a bit of Excel logic that looked for C in a particular slice and segment of the image to be greater than the C for the same L & H with sRGB. Those are the colours you want. They have a higher Chroma than permitted in sRGB.
The worksheet gives you the co-ordinates of those original samples so in your Excel be sure not to lose them.
CTP will give you an image if you format your sample data correctly but that may not be sufficient for you. 
At some point you would want to display them and would need a large gamut printer to do so. There would be no point in attempting to print them or display them in sRGB as the software would attempt to put them in gamut which then makes all your work pretty irrelevant, however it still might produce an interesting image, just not what you described as your desire.
Whatever display technique you use again OoG colours would be moved in some way to make them visible. If you don't want that you would need to do something like the above again with your larger gamut to remove those OoG colours so that you were not "cheating" :-)

I think that turning the Lab colours and co-ordinates into a useable image is probably going to be the interesting bit of work. The stuff with Excel is just a bit boring.

I broke my pelvis and during my recovery I used my 400,000 samples to produce "Rex's Gamut", so it isn't a quick job.
I give a talk based on this work and one of my slides says "Don't do this at home" 

Make sure your chosen image(s) are OoG in sRGB before you do all the maths! Gamut warning in PS can be set up to do that.

Best of luck. It will be interesting to see if there are simpler solutions.
Regards Rex



John Phillips
 

Thank you Rex, this is a extremely helpful. I didn't know about CTP, but have just downloaded a demo now and it looks fascinating. If it's ok with you I may come back with a couple of questions when I have experimented with CTP.


Henry Davis
 

Your last sentence is a doozy.

I believe the answer to where out of gamut colors go is: ‘away’ as in gone - but the numerical Lab values could be kept for reference in a duplicate of the Lab image.

If memory serves there is/was a Photoshop display option for displaying out of gamut colors as grey.

Reproducing out of gamut colors depends on the gamut of either ink or display as well as the illuminant. I believe even a plot or graph representation of a gamut will need the illuminant figured in as well. I suppose one could mix paint for a painting that would be entirely out of gamut for some methods of reproduction or even outside human perception - such as ‘invisible ink’, fluorescent colors or things that appear in infrared or ultraviolet. There are gamuts, and then there are some gamuts that are way out there.

There are lots of things we can’t perceive even though people have had a go at explaining what they would be like if we could. Humans have a different ability for hearing sound than animals. Animals also see differently than humans. Scientists try to demonstrate how animals visually perceive the world using odd-looking pictures. I’ve always thought those demonstrations fall way short for, by definition, human perception is not the same.

So, I wonder what you’re up to with this project. If you can say, what is the nature of the image you hope to produce (even if blank)?

Henry Davis

On Sep 8, 2020, at 7:13 AM, John Phillips <paulsimonrichards@...> wrote:

Hi, I am curious about what happens to out of gamut colours during an Lab - to RGB conversion - where do they go and is there a way to keep this information?

As I understand it, when a L*a*b image is converted to RGB, the colour values are clamped to fit into the 255 range, leaving legal representations of colours.

I wondered if it is theoretically possible to conduct this conversion and store on file only the data which is out of gamut, without the proxy colours?

Mr Margulis' work has inspired me for nearly 2 decades, I am an artist working on an experimental project and would like to produce files which are entirely out of gamut, with nothing visible to SRGB. Even if this means producing a blank image.

Thank you


John Phillips
 

Your last sentence is a doozy.
Respectfully, I don't understand this comment.

While I understand that I am coming in from the left field somewhat, but I hope that my question comes across as valid within this group.
I am trying to produce an animation which paradoxically contains a wealth of colour information, yet cannot be seen with standard screen technology.

I am working with software developers for a well known 3D render engine to allow for Lab output of animation frames to produce OoG images from the jump.
If this is not possible then I will render in RGB and then undertake exaggerated Lab colour modifications in Photoshop, pushing the chroma values OoG.
I would then like to undertake some kind of boolean operation to separate the data which remains legal and that which is OoG. Rex's suggestion to work with Color Think Pro seems like a good starting point.

With this data I then hope to compile the animated frames as a video, ideally in L*a*b keeping the OoG data, but for the sake of final presentation the file will have to be converted back to sRGB
at which point I would like the OoG information to be more or less invisible on screen.

This may all seem rather silly, but it's a work that is accompanied by a full description of process and I would like to be as truthful to my materials and the Lab colour space as I can be.

Thanks for your time



Rex Waygood
 

Strangely it is the kind of thing I love doing, so ask away.
You will notice there are lots of resources, a colorwiki and a forum, I guess others will be interested in your idea and be able to offer help.
Remember I have not done this so you may end up with an insuperable problem and be unable to achieve your objective.

When I set out to do my paper in knew little and worse didn't really know where I was going :-)
When I finished I knew a bit more and knew I had arrived :-)
An example of my naivety, I mathematically converted Lab coordinates to LCH and then found CTP had that option. :-) 

Rex


Rex Waygood
 

If you are working with video then there is some serious processing to do due to frame rate and the final sample size. Wow what fun:-)
The reconstruction of the OoG image will then really be hard.

With video the best gamut isn't that much bigger than sRGB.
You can drop P3 and sRGB into CTP and discover your working space.

This is stopping me doing things that should be done! :-)


Dan Margulis
 



On Sep 8, 2020, at 9:53 AM, John Phillips <paulsimonrichards@...> wrote:

I am trying to produce an animation which paradoxically contains a wealth of colour information, yet cannot be seen with standard screen technology.

I’m not sure there’s a basis for that statement. The file may be in LAB and it may contain “colors” that are outside the gamut of (say) sRGB but the monitor that displays the LAB file is an RGB device, so the LAB file, with rare exceptions, closely resembles what you’ll get upon conversion to sRGB.

The usual cause for concern is that somebody is trying to use LAB to force more color into a file destined for some other colorspace, not realizing that the LAB file already specifies something OOG for that space. Do this, and all that happens is that detail starts to go away.

So if you recover the parts of the file that are OOG chances are they will display differences in detail. The differences in color would be difficult to evaluate except by artificial instrument.

If you must see a close approximation of the difference, here is the procedure; for the sake of argument I assume you are concerned about an LAB>sRGB conversion.

Starting with the LAB file believed to contain OOG colors,

1) Make one copy and convert it to sRGB. Chances are you won’t see a difference.

2) Make a second copy of the LAB file and convert it to ProPhoto RGB, which technically speaking contains almost all the LAB gamut and almost certainly won’t show a visible difference.

3) Convert the sRGB version to ProPhoto RGB.

4) Put one of your two files that are now ProPhoto RGB as a layer on top of the other.

5) Change layer mode from Normal to Difference. Chances are, it will look black.

6) Duplicate this file, flattening it. Still looks black.

7) Auto Tone. This will display the differences that were previously hidden by black, showing the differences between the LAB>ProPhoto and the LAB>sRGB>ProPhoto files, which are basically those colors outside of the sRGB gamut.

That should be close enough, but for more accuracy you should turn off the automatic dithering in the conversion as that will produce some fine noise that really isn’t OOG. Also, rather than Auto Tone, it’s slower but more accurate to apply a straight-line curve to the Difference file, moving the highlight point inward until detail starts to appear out of the blackness.

Dan Margulis


Henry Davis
 

That’s ok, I couldn’t understand what your project was about and frankly still don’t see the point of it.  But, this is a shortcoming on my part and I thank you for the additional information in this post.

The last sentence in the OP reads:

"Even if this means producing a blank image.”

That caused me to wonder what a blank image might accomplish for you as an artist.  I meant no disrespect with the word ‘doozy’.

I’ll see myself out now.

Henry Davis

On Sep 8, 2020, at 9:53 AM, John Phillips <paulsimonrichards@...> wrote:

Your last sentence is a doozy.
Respectfully, I don't understand this comment.

While I understand that I am coming in from the left field somewhat, but I hope that my question comes across as valid within this group.
I am trying to produce an animation which paradoxically contains a wealth of colour information, yet cannot be seen with standard screen technology.

I am working with software developers for a well known 3D render engine to allow for Lab output of animation frames to produce OoG images from the jump.
If this is not possible then I will render in RGB and then undertake exaggerated Lab colour modifications in Photoshop, pushing the chroma values OoG.
I would then like to undertake some kind of boolean operation to separate the data which remains legal and that which is OoG. Rex's suggestion to work with Color Think Pro seems like a good starting point.

With this data I then hope to compile the animated frames as a video, ideally in L*a*b keeping the OoG data, but for the sake of final presentation the file will have to be converted back to sRGB
at which point I would like the OoG information to be more or less invisible on screen.

This may all seem rather silly, but it's a work that is accompanied by a full description of process and I would like to be as truthful to my materials and the Lab colour space as I can be.

Thanks for your time


Kirk Thibault
 

One approach that may be interesting and is more graphical and qualitative as opposed to quantitative, spreadsheet manipulation is the following….

Start with a full Lab image (for example, make a new document in PS in Lab color - fill the L channel with L50, fill the a channel with a left-to-right,  black-to-white linear gradient, zero smoothness, fill the b channel with a top-to-bottom, black-to-white gradient, zero smoothness.  Make a set of Lab images, say in L10 increments, by duplicating the above document and replacing the L channel fill with L0, L10, L20 … L100.

Set the working color space for PS to the color space that you want to compare to Lab (for example, sRGB).  Open one of the Lab images and simply change the mode from Lab to RGB - this will place the Lab colors into the current working color space.  As Dan pointed out, real images do not change appearance very much, but the smooth gradients of color will show some banding and discontinuity when you perform this operation.  The real interesting thing about this change of mode though, is the R, G and B channels in the RGB document, which are grayscale representations of the color.  This is where, regardless of the ability of your color display, you can see clipping that occurs in the change from Lab to RGB - clipped values in each channel go to black.  You can examine each channel and combine all of the channels’ grayscale images into a single grayscale image with BlendIf permitting you to threshold each of the three images (R, G and B channel representations) into a single image, against a white background layer, that shows you what it is gamut (white) and what has been clipped (black).  Repeat this operation for each level of L that you made in the original L series of images.  You can make an action that will automate the process after you open a L image:

1) Change the mode to RGB
2) Make a new layer above the background layer and fill with white
3) Make a new layer - Apply Image … Normal blend mode, Background layer, RED Channel
4) Make a new layer - Apply Image … Normal blend mode, Background layer, GREEN Channel
5) Make a new layer - Apply Image … Normal blend mode, Background layer, BLUE Channel
6 Select the BLUE layer and adjust the BlendIf by dragging the “This Layer” white slider down to a value like “5” or so - repeat for the GREEN and RED layers.
7) Stamp a copy of the resulting composite.

Now you have a binary image of the gamut for that slice of L.  Not surprisingly, it looks like the gamut volume for sRGB in Lab coordinates.  You can do this for any image, preferably by converting a raw digital camera image file directly into Lab (ACR will do this, as will some other raw converters).  You can also mess with the fall off and threshold of the BlendIf operation to get the effect that you are looking for, in terms of how the boundary of the gamut appears in each image.

What is interesting is the abstract image that can result from layering the resulting binary images and compositing them - you can do this with a Smart Object (load images to stack and make a Smart Object) and then play with the Smart Object stack mode - Entropy is interesting.  You might also get interesting effects if you combine different binary images into R, G and B channels of a new RGB document, producing a Harris Shutter kind of effect.

Or…

For a given pixel in your Lab document at a given X,Y image location, you could extract the L, a and b value of the pixel and perform a simple distance calculation (SQRT(a^2 + b^2)) at the pixel’s L plane and compare that distance to the distance of the sRGB gamut volume boundary on the specified L plane in the direction specified by the direction of the ab vector in Lab.  If the ab distance is greater than the corresponding point intersected on the sRGB gamut volume boundary, then the result is “0” (OOG), else the result is “1” (in gamut).

Kirk Thibault

On Sep 8, 2020, at 9:53 AM, John Phillips <paulsimonrichards@...> wrote:

Your last sentence is a doozy.
Respectfully, I don't understand this comment.

While I understand that I am coming in from the left field somewhat, but I hope that my question comes across as valid within this group.
I am trying to produce an animation which paradoxically contains a wealth of colour information, yet cannot be seen with standard screen technology.

I am working with software developers for a well known 3D render engine to allow for Lab output of animation frames to produce OoG images from the jump.
If this is not possible then I will render in RGB and then undertake exaggerated Lab colour modifications in Photoshop, pushing the chroma values OoG.
I would then like to undertake some kind of boolean operation to separate the data which remains legal and that which is OoG. Rex's suggestion to work with Color Think Pro seems like a good starting point.

With this data I then hope to compile the animated frames as a video, ideally in L*a*b keeping the OoG data, but for the sake of final presentation the file will have to be converted back to sRGB
at which point I would like the OoG information to be more or less invisible on screen.

This may all seem rather silly, but it's a work that is accompanied by a full description of process and I would like to be as truthful to my materials and the Lab colour space as I can be.

Thanks for your time




Rex Waygood
 

I couldn't get my head round this working as John wanted. It will do something but not quite what John described. I had thought of it as a possible solution.
When the conversion is made to sRGB the OoG colours will be put on the periphery of the sRGB gamut.
When the difference is taken the result will not be the sRGB gamut subtracted from the ProPhoto Image but the subtraction will be the sRGB image plus the OoG colours using RC Intent. If Perceptual were available that would cause more non-John results.  
The results might satisfy his artistic intent but I am not convinced it meets his stated intent.
Rex


Rex Waygood
 

I expected this to be under Dan's post. It isn't on my screen.


k_d@...
 

I have always found interesting Lab info at this website...look around various pages and you might find your answer...
http://www.brucelindbloom.com/index.html?LabGamutDisplayHelp.html

Doug Schafer


Rex Waygood
 

Agreed, he is the colour oracle in the maths/science arena :-)


Michael Jahn
 

Hi John

( i copied you directly as I am not sure if the io form scrum technology allows html embedded image in the reply - that way you should get the image in this reply )

see;

http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html#SideNotes

Paragraph 3 should be of interest to you then..

The first entry in the table is the Lab Gamut. This is the set of Lab color coordinates for which there could possibly be a physical sample. These are the "real colors." Lab color coordinates that lie outside this gamut can never exist in nature, and therefore it is not important that these coordinates be represented in a working space definition. Further information about the Lab Gamut may be found here 

http://www.brucelindbloom.com/index.html?LabGamutDisplayHelp.html

and 3D images of it may be found 
here.  

http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html#SideNotes

i especially like this part

Integer Encoding of Lab

Many real world implementations of Lab encode the values as integers. Common examples include TIFF image files, ICC profiles and Adobe Photoshop images. Integers have limited ranges. Typically, the full L* range [0, 100] is encoded. However, the encoding range of the a* and b* components is usually restricted to cover the range [-128, 127]. Therefore, all possible Lab colors cannot be encoded using this scheme. Even when 16-bit values are used instead of 8-bit values, the extra bits are used to make finer divisions between values, and are not used to extend the range of values.

Here is an illustration showing the limits imposed by this integer encoding of Lab:

LabGamutIntegerAnnotated.jpg

The semi-transparent boxes show the portion of Lab color space that may be represented by integer encoding. You can see that some real colors are excluded (the lobes that bulge outside the box). You can also see that much of the available encoding space, about two-thirds in fact, is wasted because these Lab values can never occur.  

Hope this helps.

Respectfully,

Michael Jahn
2718 Cimmaron Ave
Simi Valley, CA 93065

805 416 6946


On Tue, Sep 8, 2020 at 5:05 AM John Phillips <paulsimonrichards@...> wrote:
Hi, I am curious about what happens to out of gamut colours during an Lab - to RGB conversion - where do they go and is there a way to keep this information? 

As I understand it, when a L*a*b image is converted to RGB, the colour values are clamped to fit into the 255 range, leaving legal representations of colours. 

I wondered if it is theoretically possible to conduct this conversion and store on file only the data which is out of gamut, without the proxy colours? 

Mr Margulis' work has inspired me for nearly 2 decades, I am an artist working on an experimental project and would like to produce files which are entirely out of gamut, with nothing visible to SRGB. Even if this means producing a blank image. 

Thank you


k_d@...
 

"Here is an illustration showing the limits imposed by this integer encoding of Lab:"

3D view is nice.

I made a layered 2D .pdf view and posted to this group ... years ago.
check here:  https://groups.io/g/colortheory/files/2015%20and%20earlier/Doug.S%20LAB%20curves
And check out the Lab gamut diagram.pdf
Useful to check if a test sample (Lab #s) in Lab, is in gamut...look it up on the chart.
Also useful to note at various L levels, where the a and b values are limited/out of gamut.
If anyone wants individual layers, I can post them here too.

Open .pdf and, for example, you can see that at L=50, lower left teal colors (-a and -b) are limited, and upper greens/yellows/reds are limited to b<80

Doug Schafer