Luminous Landscape Forum
Raw & Post Processing, Printing => Other Raw Converters => Topic started by: MirekElsner on December 31, 2013, 10:14:26 pm
-
As weird as it sounds, I am looking for a raw converter that supports direct conversion to Lab or can capture colors that are outside of ProPhoto RGB gamut. Is there any?
-
As weird as it sounds, I am looking for a raw converter that supports direct conversion to Lab or can capture colors that are outside of ProPhoto RGB gamut. Is there any?
The more recent versions of Adobe Camera Raw can render into L*a*b but do so from their internal working space which uses ProphotoRGB primaries and the resulting output can not exceed the Prophoto gamut. According to Bruce Lindbloom (http://www.brucelindbloom.com/WorkingSpaceInfo.html), ProphotoRGB covers 91.2% of the L*a*b gamut. This is more than sufficient for practical work, since no currently available output device can come anywhere near to reproducing the entire L*a*b gamut. Furthermore, ProphotoRGB exceeds the gamut of real world surface colors (reflective colors seen in nature, see page 10 of this document (http://www.fho-emden.de/~hoffmann/gamuts08072002.pdf)). Additional gamut would be needed to encode emissive sources such as neon lights.
Interestingly, integer encoding of L*a*b as done in Photoshop and many other applications can encode only 97% of the L*a*b gamut, and I think that it is unlikely that any common raw converter could represent the entire L*a*b gamut.
Regards,
Bill
-
I suspect every raw converter at some point starts with an RGB assumption going out to whatever. So a direct conversion to Lab from what?
-
the gamut of real world surface colors (reflective colors seen in nature
but real world != reflective colors seen in nature... because nowadays you have to deal w/ artificial ones (even not emissive).
-
As weird as it sounds, I am looking for a raw converter that supports direct conversion to Lab or can capture colors that are outside of ProPhoto RGB gamut. Is there any?
try rpp
-
I suspect every raw converter at some point starts with an RGB assumption going out to whatever. So a direct conversion to Lab from what?
Since the Bayer CFA is an RGB device, that sounds like a reasonable assumption. Chapter 6 of the Adobe DNG specification deals with mapping of the camera color space to CIE XYZ, suggesting that this mapping is performed in Adobe raw conversion. As I understand things, CIE Lab is a mathematical derivation of CIE XYZ, and the Lab values could be derived with no loss of data from the XYZ values.
Bill
-
I suspect every raw converter at some point starts with an RGB assumption going out to whatever. So a direct conversion to Lab from what?
Exactly. It might help if the OP explained why he thinks that direct CIELab encoding offers a benefit, maybe he's after something that's useful, but I have my doubts. Even conversion from camera RGB space to CIELAB would require floating point numbers to avoid quantization steps that are too large to be accurate.
Cheers,
Bart
-
Exactly. It might help if the OP explained why he thinks that direct CIELab encoding offers a benefit, maybe he's after something that's useful, but I have my doubts. Even conversion from camera RGB space to CIELAB would require floating point numbers to avoid quantization steps that are too large to be accurate.
Cheers,
Bart
There is no practical reason. I just want to see what colors is my camera (after post processing) able to produce. I know there are at least some colors outside of ProPhoto, because I can see some clipping when looking at some color plots.
The attached image shows a lot of colors from a shot of some trees (the picture is mostly green) into xyY coordinates. This is a ProPhotoRGB image (from LR) and the red triangle shows boundaries of the embedded profile. There is some clipping of the greens, less extensive but similar as what I see with plots made from images converted from ProPhoto to colorspaces like AdobeRGB, so I guess there is more to see if I use appropriate converter (and more colorful captures).
-
try rpp
Thanks!
-
There is no practical reason. I just want to see what colors is my camera (after post processing) able to produce. I know there are at least some colors outside of ProPhoto, because I can see some clipping when looking at some color plots.
Hi Mirek,
I understand. Do realize though, that the color plots are based on approximated RGB coordinates that change when e.g. a lower saturation is used during Raw conversion. You are almost certainly not looking at spectrophotometrically correct color coordinate positions. Also, the larger the gamut is, the larger the quantization steps between subsequent integer number coordinates (that's why I mentioned that floating point numbers would be required). Also, most actual images do not fully use the full gamut space, and in fact Prophoto RGB also has the room to encode non-existing colors that will therefore never be used.
The attached image shows a lot of colors from a shot of some trees (the picture is mostly green) into xyY coordinates. This is a ProPhotoRGB image (from LR) and the red triangle shows boundaries of the embedded profile. There is some clipping of the greens, less extensive but similar as what I see with plots made from images converted from ProPhoto to colorspaces like AdobeRGB, so I guess there is more to see if I use appropriate converter (and more colorful captures).
Yes, good example, although the xyY plot only shows the coordinates at a certain Luminance level, and the space is not perceptually uniform (the issue may more, or less, significant when shown in e.g the CIE 1976 (L*, u*, v*) (http://en.wikipedia.org/wiki/CIELUV) color space), especially in 3D.
What you probably want, and you'd not be the only one, is a better Saturation clipping indicator (not only that it's clipping, but also by how much), and tools to convert between (or specifically towards output) colorspaces.
As other threads here on LuLa and elsewhere have demonstrated, the Raw data may be unclipped before White-balancing, but combined with a given exposure level that data may become Out-Of-Gamut (OOG) after white-balancing. So the actual Raw conversion may already address some OOG issues later in the workflow, without the need for a wider gamut colorspace.
The drawbacks of an 'Mega' large colorspace (e.g. posterization risk with large manipulations and inaccurate colors due to sparse linear quantization with integer coordinates), may outweigh the benefits for a few colors that could be addressed/tamed in a different way.
Cheers,
Bart
-
Do realize though, that the color plots are based on approximated RGB coordinates that change when e.g. a lower saturation is used during Raw conversion. You are almost certainly not looking at spectrophotometrically correct color coordinate positions. Also, the larger the gamut is, the larger the quantization steps between subsequent integer number coordinates (that's why I mentioned that floating point numbers would be required). Also, most actual images do not fully use the full gamut space, and in fact Prophoto RGB also has the room to encode non-existing colors that will therefore never be used.
That's fine, I am interested in data after post processing into visually compelling image. That may theoretically involve not only WB/exposure and other changes in the raw converter, but also other accuracy crippling factors like use of polarizer, redhancer or GND filters.
Yes, good example, although the xyY plot only shows the coordinates at a certain Luminance level, and the space is not perceptually uniform (the issue may more, or less, significant when shown in e.g the CIE 1976 (L*, u*, v*) (http://en.wikipedia.org/wiki/CIELUV) color space), especially in 3D.
This particular plot shows all Y levels. I convert the RGB to XYZ and then to xyY and plot all unique colors I found in the image. So a single point in the diagram quite often has multiple stacked values with higher Y on the top. The points are plotted with their original color value, so some hint of Y can be seen from their actual luminosity. Basically, you are looking at xyY 3d diagram from the top.
What you probably want, and you'd not be the only one, is a better Saturation clipping indicator (not only that it's clipping, but also by how much), and tools to convert between (or specifically towards output) colorspaces.
Yes, that is what I am trying to accomplish. I started with visualization of the data in 2d, next step is 3d. I am thinking about visualizing ∆E as well. And while I am working on it, I noticed this clipping in ProPhotoRGB. My tool is RGB-based and any image non-RGB image opened in it must be converted to RGB. That's why I am trying understand what I am potentially throwing away if I open an image in something bigger, that means, possibly a Lab image.
I wanted to point out two things in the attached screenshot:
- The clipping so far always occurs on the right side of the diagram, where it coincides with boundary of the spectral locus. Output gamuts of 2014 aside, I am not sure how practical it would be to salvage these.
- There are two areas where there are visible colors outside of ProPhoto RGB - greens and purples. The areas are not small. I wonder what colors would fit there, I could not find any, yet.
Thanks,
m
-
Can you show a screen capture of the histogram of that image within ACR or LR.
-
The more recent versions of Adobe Camera Raw can render into L*a*b...
Shame we can't do that within Lightroom.
I can produce a histogram that shows no clipping in ProPhoto RGB that then does in Lab within ACR. That seems to illustrate the potential problems with color spaces that encode 'colors' we can't see like ProPhoto RGB. Yank on Saturation in ACR and depending on the image, you can define something we can't see ::)
In ACR, open Workflow options and toggle while viewing the histogram update.
-
Can you show a screen capture of the histogram of that image within ACR or LR.
Sure, I'll try to attach LR raw histogram, LR gamut warning preview with ProPhoto RGB soft proof and PS histogram of the actual tiff that was used for the plot. It crashes on me so I will try one by one. Just yesterday I browsed through The Digital Print from Jeff Schewe and he had a side note there indicating that according to Eric Chan the LR histogram does not show everything. Just saying...
-
Now the soft proof...
-
And PS histogram...
-
What you want to do is save those settings for the raw, open in ACR if you have it. Should appear the same. Set workflow options for Lab. Do you see clipping?
-
Shame we can't do that within Lightroom.
I can produce a histogram that shows no clipping in ProPhoto RGB that then does in Lab within ACR. That seems to illustrate the potential problems with color spaces that encode 'colors' we can't see like ProPhoto RGB. Yank on Saturation in ACR and depending on the image, you can define something we can't see ::)
In ACR, open Workflow options and toggle while viewing the histogram update.
Here is one such example where there is clipping when rendering into Lab but none in ProPhotoRGB
Bill
-
What you want to do is save those settings for the raw, open in ACR if you have it. Should appear the same. Set workflow options for Lab. Do you see clipping?
Here we go. How does the Lab gamut look like, does it follow the spectral locus?
Btw, I did couple more experiments. I looked at the image in raw digger and the raw has clipping in the B channel. I wonder why it does not appear in LR... I also tried RPP. It would probably take some time to tame it, but at least I managed to see the histogram - it shows clipping in green and after WB also in reds.
-
And PS histogram...
You need to refresh the histogram of this image as indicated by the ! in the triangle.
Bill
-
I noticed this soon after posting, but the histogram was the same after refresh.
-
Raw Therapee allows you to use _any_ RGB profile you want as working and output spaces. If you create a super wide color profile in PS using Color Settings and use that as your working and export profiles, you should be able to get what you want.
-
There is no practical reason. I just want to see what colors is my camera (after post processing) able to produce.
If you'll humor me, I'd like to back up a little bit. Cameras don't see colors. Color is a human-centric construction. Cameras see intensity in three spectral sets, the spectra being determined by the wavelength-by-wavelength multiplication of the sensitivity of the camera's sensor, the color filter array's spectral response, and the spectral response of the lens/filter. Raw processing converts the data in camera file to colors. The process is decidedly imperfect. The camera doesn't see spectra like a color-normal (or, actually, any) human. The camera responds to wavelengths to which we are insensitive. The camera produces RGB triples that are identical for spectral stimuli that produce different colors when viewed by a human. The camera produces RGB triples that are different for spectral stimuli that produce identical colors when viewed by a human.
You said "(after post processing)", so maybe you understand all that. However, since post processing can cover just about any operation, the answer to your question is dependent entirely on the color space of the raw processor. Unless the raw processor attempts to save you from yourself, you should be able to produce any triple in the gamut of the raw processor's color space. If that color space includes triples that represent stimuli invisible to humans, you should be able to produce those triples. However, I wouldn't call them "colors".
Jim
-
Well stated Jim! There's a lot more going on under the hood, cameras record what we can't see and are not colors, we can see colors it can't record. And ProPhoto RGB has numeric definitions that are not colors.
-
Mirek, if you're looking for a color space in which to examine the output of a raw converter, I suggest that CIEL*u*v* is more appropriate than CIEL*a*b*. Although Luv shares a deficiency of Lab -- you can represent stimuli that aren't visible colors -- at least with Luv there's a clear boundary -- the conical horseshoe -- that separates colors from abstract triples. Luv has the big advantage for your purposes that it can represent any visible color. In addition, Luv has the concept of saturation, which is defined as how much chroma is in a particular triple as a percentage of the maximum visible chroma at that luminance and hue angle. Also, we're used to looking at chromaticity diagrams, and a horizontal slice through a Luv solid is the u'v' chromaticity plane.
Unfortunately (at least I think it's unfortunate), Luv is not commonly used by photographers. There are historical reasons for this that no longer apply. In 1976, when Lab and Luv were standardized, the print community had used Lab for years, and didn't want to change. The video folks had been using Luv, and felt the same way. They couldn't compromise, and standardized both. You can see the history in the default white points: D50 for Lab, and D65 for Luv. Then along came Photoshop. Since it was aimed initially at the print community, it supported Lab. Twenty-five years later, when a photograph is as likely to find its final destination on a LCD screen as a printed page, Photoshop still doesn't support Luv. It's a pity.
This doesn't really have much to do with the original post, but I couldn't help myself.
Jim
-
You said "(after post processing)", so maybe you understand all that.
Jim
Yes, I said "(after post processing)" on purpose. I am interested in typically processed end result where camera is only one link in the chain.
However, since post processing can cover just about any operation, the answer to your question is dependent entirely on the color space of the raw processor. Unless the raw processor attempts to save you from yourself, you should be able to produce any triple in the gamut of the raw processor's color space. If that color space includes triples that represent stimuli invisible to humans, you should be able to produce those triples. However, I wouldn't call them "colors".
I am mainly interested in seeing which visible colors are clipped in the processing chain based on ProPhoto RGB - that would be the blues and purples. I am interested in a "standard" pictorial processing workflow. Most people do not crank up the saturation all the way to the right and if they do, I don't care about these extremes... This is just curiosity, I don't see any practical use for it.
-
Mirek, if you're looking for a color space in which to examine the output of a raw converter, I suggest that CIEL*u*v* is more appropriate than CIEL*a*b*. Although Luv shares a deficiency of Lab -- you can represent stimuli that aren't visible colors -- at least with Luv there's a clear boundary -- the conical horseshoe -- that separates colors from abstract triples. Luv has the big advantage for your purposes that it can represent any visible color. In addition, Luv has the concept of saturation, which is defined as how much chroma is in a particular triple as a percentage of the maximum visible chroma at that luminance and hue angle. Also, we're used to looking at chromaticity diagrams, and a horizontal slice through a Luv solid is the u'v' chromaticity plane.
Unfortunately (at least I think it's unfortunate), Luv is not commonly used by photographers. There are historical reasons for this that no longer apply. In 1976, when Lab and Luv were standardized, the print community had used Lab for years, and didn't want to change. The video folks had been using Luv, and felt the same way. They couldn't compromise, and standardized both. You can see the history in the default white points: D50 for Lab, and D65 for Luv. Then along came Photoshop. Since it was aimed initially at the print community, it supported Lab. Twenty-five years later, when a photograph is as likely to find its final destination on a LCD screen as a printed page, Photoshop still doesn't support Luv. It's a pity.
This doesn't really have much to do with the original post, but I couldn't help myself.
Jim
Excellent information. I will check to see if I can find formulas for converting between XYZ and Luv so that I can use it.
-
Excellent information. I will check to see if I can find formulas for converting between XYZ and Luv so that I can use it.
Here you go:
http://en.wikipedia.org/wiki/CIELUV#XYZ_.E2.86.92_CIELUV_and_CIELUV_.E2.86.92_XYZ_conversions
-
Well stated Jim! There's a lot more going on under the hood, cameras record what we can't see and are not colors, we can see colors it can't record. And ProPhoto RGB has numeric definitions that are not colors.
I think though that they did a very good job at specifying the primaries in a way that the color space covers most visible colors and not so much garbage.
-
Unfortunately (at least I think it's unfortunate), Luv is not commonly used by photographers. There are historical reasons for this that no longer apply. In 1976, when Lab and Luv were standardized, the print community had used Lab for years, and didn't want to change. The video folks had been using Luv, and felt the same way. They couldn't compromise, and standardized both. You can see the history in the default white points: D50 for Lab, and D65 for Luv. Then along came Photoshop. Since it was aimed initially at the print community, it supported Lab. Twenty-five years later, when a photograph is as likely to find its final destination on a LCD screen as a printed page, Photoshop still doesn't support Luv. It's a pity.
Jim,
What photo processing programs that use Luv are available?
Bill
-
What photo processing programs that use Luv are available?
For processing, none, AFAIK.
There's an ImageJ visualization tool that supports Luv, but I haven't used it:
http://rsb.info.nih.gov/ij/plugins/color-inspector.html
[added later: I'm not suggesting that CIELuv is a good space in which to perform photographic manipulations, although it's probably no better and no worse than Lab for that purpose; I'm saying it's a good space to look at how colors in an image relate to the gamut of human vision.]
Jim
-
For processing, none, AFAIK.
There's an ImageJ visualization tool that supports Luv, but I haven't used it:
http://rsb.info.nih.gov/ij/plugins/color-inspector.html
[added later: I'm not suggesting that CIELuv is a good space in which to perform photographic manipulations, although it's probably no better and no worse than Lab for that purpose; I'm saying it's a good space to look at how colors in an image relate to the gamut of human vision.]
Jim
Jim,
I downloaded and installed the color-inspector plugin into ImageJ. It is a very nice and fast application, but it assumes that a RGB image is in sRGB, so it is not useful for evaluating "colors" that are outside the gamut of human vision.
Here is a Colorthink plot of the image that I previously used to show ProPhotoRGB and Lab renderings of a shot of flowers with saturated colors. The image was rendered into ProPhotoRGB with ACR. There is a cliff at the right edge of the plot which I interpret as indicating the presence of imaginary "colors". Is this correct?
Bill
-
I downloaded and installed the color-inspector plugin into ImageJ. It is a very nice and fast application, but it assumes that a RGB image is in sRGB, so it is not useful for evaluating "colors" that are outside the gamut of human vision.
Sorry about that.
Here is a Colorthink plot of the image that I previously used to show ProPhotoRGB and Lab renderings of a shot of flowers with saturated colors. The image was rendered into ProPhotoRGB with ACR. There is a cliff at the right edge of the plot which I interpret as indicating the presence of imaginary "colors". Is this correct?
I don't think so, Bill. Take a look at this chromaticity plot:
(http://blog.kasson.com/wp-content/uploads/2012/08/ProPhotoRGB-uv.jpg)
You can see that the red ProPhotoRGB primary is visible, and the green almost so. The blue primary is the one that's wildly out there. The cliff that you're talking about, I think, is along the line that connects the red and green primaries, which is right at the edge of what we can see, but for the most part, not outside it.
Jim
-
Here is a Colorthink plot of the image that I previously used to show ProPhotoRGB and Lab renderings of a shot of flowers with saturated colors. The image was rendered into ProPhotoRGB with ACR. There is a cliff at the right edge of the plot which I interpret as indicating the presence of imaginary "colors". Is this correct?
Bill
How does it look like if you rotate the diagram so that the spectral locus in at the bottom and the pixels on top? Are there any pixels outside of the spectral locus?
-
How does it look like if you rotate the diagram so that the spectral locus in at the bottom and the pixels on top? Are there any pixels outside of the spectral locus?
Mirek, the way I view Bill's image is that the spectral locus is at the bottom (it's the curved part of the periphery of the white, flat thingie), and we're looking at the plot from outside the red end of the magenta line that's the flat part of the horse-shoe.
Jim
-
Mirek, the way I view Bill's image is that the spectral locus is at the bottom (it's the curved part of the periphery of the white, flat thingie), and we're looking at the plot from outside the red end of the magenta line that's the flat part of the horse-shoe.
Jim
Jim's interpretation is correct: the horseshoe spectral locus is on the bottom.
Here is the original plot:
(http://bjanes.smugmug.com/Photography/Spectral-Plots/i-Z4XMtgN/0/O/LuvPlot.png)
And here is the same image looking at the horseshoe from directly above:
(http://bjanes.smugmug.com/Photography/Spectral-Plots/i-4xvKmzq/0/O/LuvPlot2.png)
The ImageJ plots are of some interest even though RGB is only for sRGB. Here is the ImageJ plot of the image converted to sRGB, also as viewed from above:
(http://bjanes.smugmug.com/Photography/Spectral-Plots/i-KbbHQZj/0/O/LUV_ImageJ.png)
The HSB plot is revealing. There are many fully saturated colors.
(http://bjanes.smugmug.com/Photography/Spectral-Plots/i-qLjQp9q/0/XL/HSB_ImageJ-XL.png)
Finally, I don't see what is so special about Luv--it is another opponency space like Lab that is just as unintuitive. Perhaps Jim can enlighten us.
Bill
-
Mirek, the way I view Bill's image is that the spectral locus is at the bottom (it's the curved part of the periphery of the white, flat thingie), and we're looking at the plot from outside the red end of the magenta line that's the flat part of the horse-shoe.
Jim
I meant directly from the top, so that we could see which points are directly above the locus (visible colors) and which are not (not visible colors). Sorry for the confusion. Bill actually did it later and it seems the red, yellows and blues are outside of the locus and possibly not visible?
-
Finally, I don't see what is so special about Luv--it is another opponency space like Lab that is just as unintuitive. Perhaps Jim can enlighten us.
Bill, Luv is not the greatest thing since bottled beer. You're right, it is an opponent-color space like Lab. Is is about as perceptually-uniform as Lab, exhibiting about a 6:1 worst-case ratio on the MacAdam ellipses (http://en.wikipedia.org/wiki/MacAdam_ellipse), but the errors occur in different places. The luminance axis is the same in the two color spaces. What it has that's useful in looking at image gamuts:
- You can represent all visible colors in Luv
- You can see the boundary where the visible colors stop and the mathematical constructions begin
- You can measure how close a color is to the most chromatic a color of that hue angle and luminance can be, IOW, how saturated that color is
Lab doesn't have any of those things.
Jim
-
Bill, Luv is not the greatest thing since bottled beer. You're right, it is an opponent-color space like Lab. What it has that's useful in looking at image gamuts.
- You can represent all visible colors in Luv
- You can see the boundary where the visible colors stop and the mathematical constructions begin
- You can measure how close a color is to the most chromatic a color of that hue angle and luminance can be, IOW, how saturated that color is
Lab doesn't have any of those things.
Jim
Jim,
Personally, I prefer draft beer, but bottled beer is more convenient. :)
I'm afraid I don't know how to interpret Luv. How does one determine if a triplet is imaginary?
Thanks,
Bill
-
I'm afraid I don't know how to interpret Luv. How does one determine if a triplet is imaginary?
Bill,
I've been ignoring the asterisks and the single quotes, but I'm afraid I'm going to have to get into that to answer your question. If this turns out to be TMI, I apologize.
The plot that you posted is not actually CIEL*u*v*, usually abbreviated CIELuv or just Luv (pronounced "love"). It looks to me to be L in the vertical axis, and u' and v' in the horizontal axis. u'v' is a chromaticity space like xy. It's derived from xy as follows:
u' = 4x/(-2x+12y+3)
v' = 9y/(-2x+12y+3)
u'v' is more perceptually uniform than xy, which, among other things, gives undue prominence to the greens.
In the Lu'v' space, to see if the triplet is visible, ignore the L value and just look at u' and v'. If that pair is inside the horseshoe, the triplet is a visible color. If it's not, it's not. Pretty simple, huh?
In CIEL*u*v*, the chromaticity components are reduced by those of the white point, multiplied by a constant, and multiplied further by L*, the same luminance component as in CIELab. This has the effect of making the 3D L*u*v* visible color gamut roughly conical, with the only possible u* value for a color with an L* of zero being zero, and likewise for v*.
That makes it a little harder to look as a L*u*v* 3D plot and see the limits of visible colors. If the tool you're using doesn't provide the option of plotting the spectral locus (and it looks like the Lu'v' plot did have that option, the best thing to do is include a bunch of points that define the locus. If you want, I can whip up an Excel spreadsheet with that data; you'll also be able to see the calculations. PM me if you want that.
In my own work, I used Excel or Smalltalk to generate the data and commercial 3D graphing tools (Mathematica works fine) to plot the graphs. Now, when I have to, which is not often, I do the whole thing in Matlab.
'
Now that I've said all that, I think there's something wrong with your Lu'v' plots, if that's what they are. Before I possibly waste my time, is that what they are?
Jim
-
Bill,
I've been ignoring the asterisks and the single quotes, but I'm afraid I'm going to have to get into that to answer your question. If this turns out to be TMI, I apologize.
The plot that you posted is not actually CIEL*u*v*, usually abbreviated CIELuv or just Luv (pronounced "love"). It looks to me to be L in the vertical axis, and u' and v' in the horizontal axis. u'v' is a chromaticity space like xy. It's derived from xy as follows:
u' = 4x/(-2x+12y+3)
v' = 9y/(-2x+12y+3)
u'v' is more perceptually uniform than xy, which, among other things, gives undue prominence to the greens.
In the Lu'v' space, to see if the triplet is visible, ignore the L value and just look at u' and v'. If that pair is inside the horseshoe, the triplet is a visible color. If it's not, it's not. Pretty simple, huh?
In CIEL*u*v*, the chromaticity components are reduced by those of the white point, multiplied by a constant, and multiplied further by L*, the same luminance component as in CIELab. This has the effect of making the 3D L*u*v* visible color gamut roughly conical, with the only possible u* value for a color with an L* of zero being zero, and likewise for v*.
That makes it a little harder to look as a L*u*v* 3D plot and see the limits of visible colors. If the tool you're using doesn't provide the option of plotting the spectral locus (and it looks like the Lu'v' plot did have that option, the best thing to do is include a bunch of points that define the locus. If you want, I can whip up an Excel spreadsheet with that data; you'll also be able to see the calculations. PM me if you want that.
In my own work, I used Excel or Smalltalk to generate the data and commercial 3D graphing tools (Mathematica works fine) to plot the graphs. Now, when I have to, which is not often, I do the whole thing in Matlab.
'
Now that I've said all that, I think there's something wrong with your Lu'v' plots, if that's what they are. Before I possibly waste my time, is that what they are?
Jim
Jim,
I'm not sure what type of Luv plot I am obtaining using ColorthinkPro 3.03 on my Windows 8 machine. In reading the Colorthink documentation, I do see that they do not recommend using Luv for 3D plots:
"In general we recommend the Yxy or Luv coordinates for 2D graphing only. Lab has been found to be easier to visualize, understand, and compare when creating 3D graphs."
Here are 2D plots of the same image as used my previous posts showing the gamut of the image in color dots and that of my printer in monochrome. The image contains some blues out of the Luv gamut (human vision). The reds and greens appear slightly out of the Luv gamut. Your plots did show that ProPhotoRGB is slightly wider in gamut than Luv in these colors.
(http://bjanes.smugmug.com/Photography/Spectral-Plots/i-7Z6JWvS/0/O/LuvPlot3_2D.png)
As I understand it, 2D plots may not be optimal since they show the gamut only for one luminance value, often L* of 50, and out of gamut colors at other luminances may be missed.
Bill
-
I'm not sure what type of Luv plot I am obtaining using ColorthinkPro 3.03 on my Windows 8 machine. In reading the Colorthink documentation, I do see that they do not recommend using Luv for 3D plots:
"In general we recommend the Yxy or Luv coordinates for 2D graphing only. Lab has been found to be easier to visualize, understand, and compare when creating 3D graphs."
Bill, I downloaded the demo version of ColorthinkPro 3.03 and looked at the sRGB gamut in what they call "Luv". It must be Lu'v', because the bottom (low L) part of the gamut extends straight down from the primaries in what is in the u'v' plane, a constant sized triangle. This is not very useful, and is certainly not CIEL*u*v*. When you plot the same gamut in what they call "Lab", after some luminance, the gamut gets smaller as L goes down, culminating in a point on the bottom. That is what you'd expect for CIEL*a*b*.
Here are 2D plots of the same image as used my previous posts showing the gamut of the image in color dots and that of my printer in monochrome. The image contains some blues out of the Luv gamut (human vision). The reds and greens appear slightly out of the Luv gamut. Your plots did show that ProPhotoRGB is slightly wider in gamut than Luv in these colors.
Slightly for the green primary, wildly for the blue one. It looks like your image runs into the boundaries of the PPRGB gamut in many places, making me think that's it's been tweaked in that space.
As I understand it, 2D plots may not be optimal since they show the gamut only for one luminance value, often L* of 50, and out of gamut colors at other luminances may be missed.
Usually the 2D plots plot all the points of the 3D plots, but flatten them all onto one luminance coordinate. 2D plots thus throw away one dimension of each point. While they have their uses, 2D plots are limited, because color is inherently a three-dimensional concept.
The folks at Chromix obviously know all the color science to properly implement CIEL*u*v*. I don't know why they didn't.
Jim
-
Bill, I downloaded the demo version of ColorthinkPro 3.03 and looked at the sRGB gamut in what they call "Luv". It must be Lu'v', because the bottom (low L) part of the gamut extends straight down from the primaries in what is in the u'v' plane, a constant sized triangle. This is not very useful, and is certainly not CIEL*u*v*. When you plot the same gamut in what they call "Lab", after some luminance, the gamut gets smaller as L goes down, culminating in a point on the bottom. That is what you'd expect for CIEL*a*b*.
Jim,
Thanks for your detective work. Colorthink advertizes itself as the premier gamut graphing product, and one would expect a more useful implementation. The program is getting long in the tooth and is due for a major upgrade IMHO. It also is glacially slow and often freezes while performing its calculations and does not allow one to run other programs. ? poor multithreading, if multithreading at all.
Slightly for the green primary, wildly for the blue one. It looks like your image runs into the boundaries of the PPRGB gamut in many places, making me think that's it's been tweaked in that space.
Yes, the image was tweaked in Topaz Clarity. With a straight rendering the blues (which are not an important element of the image) are more reasonable. The image prints reasonably well with the Epson 3880 even though many colors are far out of gamut, they do not block up.
Usually the 2D plots plot all the points of the 3D plots, but flatten them all onto one luminance coordinate. 2D plots thus throw away one dimension of each point. While they have their uses, 2D plots are limited, because color is inherently a three-dimensional concept.
The folks at Chromix obviously know all the color science to properly implement CIEL*u*v*. I don't know why they didn't.
Yes. And I don't understand why they do not recommend 3D graphing with Luv. Is that because of limitations of the implementation or what they perceive to be difficulties in the interpretation of a proper implementation.
Regards,
Bill
-
...I don't understand why they do not recommend 3D graphing with Luv. Is that because of limitations of the implementation or what they perceive to be difficulties in the interpretation of a proper implementation.
If I'd implemented Lu'v' instead of CIEL*u*v* as they apparently did, I'd also recommend that you don't use it. The darker parts of images or gamuts look huge in Lu'v', where in a CIEL*u*v* implementation, like CIEL*a*b*, they'd be much smaller because of the scaling of the chromaticity components by the luminance component. This scaling is important, because it mimics a psychological effect: colors appear less chromatic as they get darker.
Jim