Update on the vanishing blue.

[xpatUSA]

That makes sense. Thanks.

I found the smaller effects of edits intriguing. A simple curve, without luminance-only blending, increases saturation. So does vibrance, although it supposedly doesn't affect already-highly-saturated areas. But if the edits are increasing saturation, wouldn't that also push down the blues in the yellow areas?

Interesting question. In the HSV/HSB color model, saturation is simply defined as (max-min)/max = 1-(min/max) where max and min are of any RGB value in a pixel:

https://en.wikipedia.org/wiki/HSL_and_HSV#Saturation

I'm not sure how an editor increases saturation but from, the above, it could either increase 'max' or reduce 'min' or both. Someone here might know. So, with our yellow/blue example, the red and green could go up or the blue could go down ... or both.

just received Brian's raw and will be posting observations later ...

[Manfred M]

Perhaps in soft-proofing the target print-profile gets used which is almost certain to have CLUTs? What do you say?

My understanding is that printer profiles are generated very much the same way as screen profiles. What I don't know is how this data is handled "under the hood".

The articles you point to are interesting to a point, but they seem to miss an important part of how commerical colour photo printing was carried out around 10 years ago. No one used Adobe software for serious print work; print shops all used proprietary RIP (Raster Image Processor) software in both the pre-press and high end photo print work. The RIP processors handled relative colorimetric the same way it is done today, but perceptual was handled by custom algorithms that were vendor specific; so the results looked different. I know a few long-time higher end photographers that used to deal with specific print shops just because they liked the way that the RIP they were using came out in their prints. Perceptual was generally the rendering intent of choice at the time; something I learned from a "master printer" I was studying under back earlier this year.

[xpatUSA]

I would be interested in the raw, too. Would like to open it in RawDigger and also RawTherapee to see what all the fuss is about!

Here are some raw histograms from Brian's camera raw file.

The full image:



Please note that the Sony black level is 512, not zero. In the full image, there is plenty blue signal, almost as much as the red.

Here is the raw histogram of a selection in the "yellow" area:



As is obvious, an amount of blue was captured by the sensor in that area. What C1 did with it I have no idea, bearing in mind that the above graphs are from camera space, not a color space.

Here is the raw histogram of a selection in the purple petal area:



Not much to say about that other than it looks about right for the petal color as converted.

Opening the raw in RawTherapee's default profile gave a horrible appearance (too much of everything). Setting all the sliders to neutral gave a dull image. After applying enough brightness, it was noticeable that the amount of blue or any other color was completely dependent on RT's output profile selection, the results being of no value in this discussion.

At least with the raw histograms above we have the starting point for all conversions and we know that Brian's original and excellent exposure neither clipped nor bottomed any sensor pixels!

[Manfred M]

original and excellent exposure neither clipped nor bottomed any sensor pixels!

That tends to suggest that the clipping of the blue channel was either the result of the PP work Brian did to the image or the way that Capture One converted the data to sRGB or a combination of the two.


Brian - would you mind sending me the link to the raw data as well? I would like to compare how Capture One processes the image versus Adobe Camera Raw.

[DanK]

That tends to suggest that the clipping of the blue channel was either the result of the PP work Brian did to the image or the way that Capture One converted the data to sRGB or a combination of the two.


Brian - would you mind sending me the link to the raw data as well? I would like to compare how Capture One processes the image versus Adobe Camera Raw.

Yes, but in my tests, simply converting to sRGB was all it took.

[xpatUSA]

Yes, but in my tests, simply converting to sRGB was all it took.

If I recall correctly, Dan, you converted from a wider color space (Adobe RGB 1998?) ... that could do it.

[Cantab]

I have nothing to contribute to the sometimes highly technical discussion in this thread. But I'm enjoying reading it.

The thread reads like a good detective novel! I have a sense that the end is now very much in sight!?

[DanK]

If I recall correctly, Dan, you converted from a wider color space (Adobe RGB 1998?) ... that could do it.

Wider, yes, but from raw, hence I assume 14 bit. That would be called "camera space," no?

[Manfred M]

Yes, but in my tests, simply converting to sRGB was all it took.

Yes, but sometimes tweaking the data in the wider colour space (brightness and or saturation will be enough to bring the image down far enough that the level of clipping is reduced and even eliminated.

The other question I am trying to answer is whether something is going on in Capture One that makes things better or worse.

[xpatUSA]

Wider, yes, but from raw, hence I assume 14 bit. That would be called "camera space," no?

No.

If we're bringing bit-depth into it, Dan, I fold. Sorry.

[JBW]

That tends to suggest that the clipping of the blue channel was either the result of the PP work Brian did to the image or the way that Capture One converted the data to sRGB or a combination of the two.


Brian - would you mind sending me the link to the raw data as well? I would like to compare how Capture One processes the image versus Adobe Camera Raw.

easy enough just send me your email

[DanK]

No.

If we're bringing bit-depth into it, Dan, I fold. Sorry.

Ted,

I no longer know what you are talking about. In post 58, I described taking a raw file, reading it into LR, and exporting as a JPEG. In post 66, you wrote about this:

If I recall correctly, Dan, you converted from a wider color space (Adobe RGB 1998?) .

There are only two files in that process: the raw file and the JPEG (which was sRGB). There is no intermediate file, so there was no Adobe RGB file from which I could be converting. (Lightoom uses a variant of ProPhoto, called Melissa, and does not offer an option of imposing a different color space for it workspace.) I couldn't understand your confusion. So in my post #70, I was simply trying to sort this out for you by reiterating that I was not working from an Adobe RGB file, but rather from a raw file. I assume his raw file was a standard 14 bit, but I had no intention of raising bit depth per se; I was simply trying to clarify for you what file I was working with.

In your post #63, you said that your graphs of the color distribution in Brian's raw file, which I was also using, is "from camera space, not a color space". In my post #68, I asked if that implies that I was starting with a file the color distribution within which would be called camera space, and you said no, with no explanation.

Perhaps this is clear to some folks, but it isn't to me.

Dan

[xpatUSA]

Ted,

I no longer know what you are talking about. In post 58, I described taking a raw file, reading it into LR, and exporting as a JPEG.
There are only two files in that process: the raw file and the JPEG (which was sRGB). There is no intermediate file, so there was no Adobe RGB file from which I could be converting.

In post #58, you wrote:

"Using the current standard ("Adobe color") ... Then I took the default Adobe color version and exported it as a JPEG at both 100% and 92% quality."

Probably clear to Adobe users but not to me, sorry, I've never used LR.

I took it to mean Adobe RGB, incorrectly it seems.

My basic comment remains: converting from a larger space such as Adobe RGB (1998) or ProPhoto to a smaller space such sRGB brings the risk of gamut clipping and/or over-saturation. This, being Color Management 101, should come as no surprise to anyone.

Sorry for the confusion.

[DanK]

Ah. that explains most of it. "Adobe standard" and "adobe color" are just rendering profiles and have nothing to do with color space. Lightroom doesn't impose a color space other than Melissa until the user exports the file in some other form, such as JPEG or TIFF. Ditto, ACR.

However, I am still confused by your use of the term "camera space" in post 63. I took this to mean the camera's native color space, but when I asked in post 68 if that is what you would call the color space is Brian's raw file, you said just "no".

[xpatUSA]

Ah. that explains most of it. "Adobe standard" and "adobe color" are just rendering profiles and have nothing to do with color space. Lightroom doesn't impose a color space other than Melissa until the user exports the file in some other form, such as JPEG or TIFF. Ditto, ACR.

However, I am still confused by your use of the term "camera space" in post 63.

In that context, I meant that the histograms of the Sony raw data from RawDigger represent "camera space" by virtue of there being no conversion or processing - as opposed to Brian's original posted JPEG which had a completely different histogram. A poor choice of term on my part, it seems.

I took this to mean the camera's native color space, but when I asked in post 68 if that is what you would call the color space in Brian's raw file, you said just "no".

The admittedly blunt "no" arose because of my own confusion re the term "Adobe color".

I try to avoid including "color" in "camera space" because that opens another can of worms about 'does camera raw data have a color space?'.

Out of curiosity, is it possible to select a working color space in LR, or is the underlying 'Melissa' all you get?

Photographers - divided by a common terminology ...

[DanK]

Out of curiosity, is it possible to select a working color space in LR, or is the underlying 'Melissa' all you get?

AFAIK, there is no way to select a color working space in LR. However, LR, like most of my editing software, maps to the display's space, so although one is working in Melissa, one sees an sRGB or Adobe RGB rendering as one works, depending on your display. I'm so used to this that I rarely think about it, and I have never seen it well explained, but it is quite apparent when I do focus stacking because the software I use, Zerene, does not map from the working space to the display space. I always export 16-bit TIFFs in ProPhoto space from LR to use in Zerene, and the colors in the TIFFs look entirely different in Zerene. They look correct again when I import the composite back into LR.

[xpatUSA]

AFAIK, there is no way to select a color working space in LR. <>

Thanks for the clarification, Dan - clears up some confusion for me as to your earlier test.

[Manfred M]

Thanks for the file Brian

I've imported the file into both Capture One and Adobe Camera Raw and have taken screenshots of what I got. No adjustments of any kind has been done and no colour space has been assigned.

1. Capture One screen capture with shadow clipping indicator enabled





2. Adobe Camera Raw screen showing shadow clipping




The whole issue being discussed has started in capture.


The areas on the Capture One screen that show solid magenta areas shows where no data was captured during the exposure. The Adobe Camera Raw capture shows the same thing, but does not show the actual image, just areas of where there is no data. The colours show the specific channels (and their complements) where this occurs.

Before doing anything else in editing and assigning a colour profile, your image is already showing signs of trouble. Having shot with an -0.3 exposure compensation is contributing to the issue as more areas will be underexposed. Had you shot with exposure compensation turned off or even slightly positive (to the point where we see no clipping in the shadows) would have given you a better starting point for your work.

Another thing to note is that there are no areas of highlight clipping showing, which means you have some headroom on that side of the exposure. A raw file is often called a "digital negative". Ideally if you get a capture with no clipping of highlight or shadow detail, you are generally open to more flexibility in your workflow.

The reason that Capture One and Camera Raw do not show identical results is that the threshold at which they show clipping is set differently in both programs. This is done because as otherwise even very small areas with problems would show up. If they are too small to have a significant impact on the final image, based on how this threshold is set, the clipping indicators do not show anything.

I'll get into a broader discussion as I assign a colour space and show some edits in future postings.

[Manfred M]

Time for the second part of the analysis. Here I took the imported raw data and assigned a colour profile and then opened the resulting image using the Camera Raw filter that is built into Photoshop. It is very similar to Adobe Camera Raw with a tiny bit less functionality (one can't change the white balance, for instance). In each case, I used the original raw data and assigned a colour profile.


1. Image 1 - converted to ProPhoto RGB colour space




2. Image 2 - converted to Adobe RGB colour space




3. Converted to sRGB colour space





4. Difference between Adobe Camera Raw and ProPhoto RGB screen captures




Looking at these three screenshots reveals a bit more of the problem.

Image 1 - Unsurprisingly, with ProPhoto RGB being the widest commonly used colour space (being about to reproduce about 80% of the colours humans can see), the clipped values that were apparent in post #78 look quite similar to what we see here. I wanted to see if they are identical so I imported the screen capture from the Adobe Camera Raw conversion and the file version converted into ProPhoto RGB and used blend mode functionality of subtract and difference to compare them. Image 4 show the result.

Some more of the colours appear to be out of gamut in ProPhoto RGB than what we saw in the original raw file.


Image 2 - Here I took the raw data and assigned the AdobeRGB colour space. It can display around 50% of the colours humans can see (I incorrectly suggested it was around 2/3 of the colours in previous postings; I went back and checked and 50% is the appropriate value). A lot more colours go out of gamut here.


Image 3 - I repeat the colour space conversion and went to sRGB with this image. There are even more out of gamut areas than in the Adobe RGB version. Brian mentioned he works in sRGB and of course, because not all web browsers handle colour spaces correctly, sRGB is what we should be using when we post images on the internet.


The second issue that Brian is running into is that on top of starting with a problematic capture, this is compounded the out of gamut issues in the various colour spaces.

[DanK]

Manfred,

A very clear explanation. thanks for posting it.

This thread began with the mystery of Brian's B=0 areas, and this thread has clearly documented that merely converting to a smaller color space can create this sort of thing. However, I think it is worth keeping track of what I showed in the middle of my tests of the sunflower image, which is that simple edits, in particular, contrast adjustments, can cause saturation problems. I first discovered this years ago when processing images of intensely red flowers. The final products had red areas in which detail had vanished, creating a plastic look. Part of the problem was unintended saturation increases. It was the first time I started using luminosity blend for contrast adjustments, in order to avoid inadvertent increases in saturation. For folks who are unfamiliar with this issue, here is a web page I found some years ago that explains it.

Dan