A Workflow with Beta RGB

[digitaldog]

"On Her Majesty's Secret Service" viewed in Audacity is a brick wall of clipped data but I swear I've never heard such fuller, louder dynamics in a piece of pop music than this selection that didn't destroy my speakers with tons of audible artifacts. It's bass heavy down to about 30hz, loud and filled with noise from the sampled original '60's movie theme. Listening on headphones is pretty scratchy sounding but in my car it's kicks ass loud and clean with no audible artifacts especially in the bass which is HEAVILY clipped.

If it looks better and sounds better clipped, that's all that counts for me.

[Tim Lookingbill]

If it looks better and sounds better clipped, that's all that counts for me.

Yeah, and from further research Flaming Lip's "At War With The Mystics" album has similar dynamics by engineer Dave Fridmann and that album won a 2007 Grammy for Best Engineered Non-Classical album, but the Loudness War bitchers still complained. Rush's 2002 "Vapor Trails" didn't get loving care in the studio amped up to 11 (it sounds really bad, I checked) and was remixed quieter in 2013.

Some engineers are just too heavy handed compressing detail, squeezing the dynamics with the equivalent of Adobe's Highlight Recovery without retaining black point.

[Robert Ardill]

The SO/ raw wasn't changed, some metadata about it might be. The equivalent of the sidecare, embedded I suspect in the PS document. If you had a raw and some metadata that said you wanted PV 2012, then you took both back to ACR or LR that was older than that PV, it wouldn't show it of course, it would "refert" to PV2010 or PV2003. I don't think that's different in Photoshop expect one would suspect the version of ACR understands the most modern features. But going back, it's the instructions that are not recognized. I don't see how the SO is different but again, I'm an novice in their use.

Hi Andrew,

Absolutely ... the embedded raw image isn't touched at all ... same as in Lightroom.  There's no history in ACR and you can't go back into the SO and do an undo of a previous step, but the edits are totally reversible, so clearly the raw data isn't changed. The editing instructions must be stored as they are in a sidecar, but inside the psd or tif.

So there's no concern about losing the raw image (anyway, I always keep the original raw file with its xmp file, so I can always go back to that).  That isn't my concern.

If you think of the Photoshop workflow it will make the issue clearer.  OK, I open the image as a raw SO in Photoshop. Fine, no problem, I can then add adjustment layers, apply a sharpening filter to the SO, crop, straighten, whatever.  Now I decide that the yellow saturation needs a tweak, so I double-click on the SO, do the edit in ACR and exit back into Photoshop.  And so on.

Now imagine that this scenario happened not now, but in 3 years time, when Lightroom/ACR has moved on to PV2016, say, so that my SO has all of its adjustments in the PV2016 context (the sliders may be different to PV2012, the effect of the sliders may be different, the demosaicing algorithm may have changed, affecting the look of the image etc.).  But now I decide I've had enough of CC, I don't want to continue to pay what has become an unacceptable annual fee for Photoshop, I am only using Photoshop occasionally by then ... whatever, basically I want to go back to the version of Photoshop I own, which is CS6.

I open the image in CC ... fine, no problem.  I decide to make a tweak to the raw SO ... I go into it ... and, hey, everything's changed ... the colors have changed, the brightness has changed ... it's just wrong!  When I go back into Photoshop the whole image has changed, even though I made no changes myself to the SO.  The problem is that ACR has reverted to PV2012, but the raw image was 'edited' in PV2016.  To give you an idea of how drastic this is, if you open a SO in PS CS4 that has been created using PV2012, the image is flipped horizontally, so left becomes right and right becomes left!

All is not lost, of course.  I can go back to the original raw image and re-develop it; I can go into ACR and correct the image based on PV2012 editing, trying to get it back to what it was in PV2016.  So it's not as though I've lost the original, I've just lost the ability to modify the raw SO without having to redo the whole raw phase of the development.  It would be sort of equivalent to an image created in CC2016 with multiple layers, filters etc., opening fine in CS6, but flattened so that all the adjustment layers, smart filters etc are lost.  Not quite as bad as that, but not far off.

Does that make sense?  So then to ensure backward compatibility we should not move to the next raw process version, but stay in PV2012 as that will (should) allow us to go back to PS CS6.

The same thing is true of Lightroom ... if you go back to Lightroom 1 and try to edit a file that has been developed in Lightroom 5 with PV2012 you will have to pretty well redo the development.  I think with Lightroom you can to some extent avoid this problem by using DNGs?  But the problem doesn't really arise with LR at this point because we can (still) purchase it outright, so you can always freeze your development environment (that's assuming that what you freeze will still run on whatever OS is available in the future ... another whole can of worms!).

Robert

[Robert Ardill]

Couple that with the property of RGB color spaces that the chromaticity gamut is small near the white point, and smell near the black point, and you can see that the chromaticity the top and the bottom of fully-populated histograms doesn't have much room to move around.

I don't quite understand what you are saying, but I think what you mean is that relative to the body of the image the regions at either end are quite narrow (a bit like the top and bottom of an apple) ... and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less).  I suppose one solution to that would be to have a histogram that is not linear, but which stretches the dark and light regions.  Or is it more than that, and are you saying that WE don't have much room to play around with at either end?  I guess this is where a full editing program like Photoshop comes into its own, as we can selectively focus on just these regions (more easily than in Lightroom).

Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images. Flowers, not so much.

Why is it that we are lucky?  We can always adjust the saturation of individual colors, surely, so if we adjust the red but it's quite separated from the blue ... so what?  I think I'm definitely missing something here.

I think we need other tools floating over the image like the histogram window, tools that take samples of the image like the histogram does, but displays those samples in some device-independent color space in cylindrical coordinates with a luminance axis, a chroma radius, and a hue angle. The user could then superimpose her choice of output device gamuts in the same display. As the user edited the image the display would keep up in real time, like the histogram (sort of) does.

Or maybe there's another way to present the information. I'm open to suggestions. As has been pointed out in this thread, gamut alarms are limited in that they don't tell you how far out you are. Maybe there's a way to modify them --false color? -- so they do.

I think a good dE-type color map as a window under the histogram (in soft-proofing mode) would be VERY useful.  Something like this:



If the editing could then be masked by the color map (more effect towards higher deltas, or edit selected range of deltas) it would be really fantastic.

Robert

[Jim Kasson]

I don't quite understand what you are saying, but I think what you mean is that relative to the body of the image the regions at either end are quite narrow (a bit like the top and bottom of an apple)

I guess I assumed too much in my post. Let me unpack the relationship of chromaticity and luminance in RGB spaces that I was trying to get at.

Any (real or imaginary) monitor-based RGB color space (called by most just an RGB color space) can be envisioned as a cube, with orthogonal red, green, and blue axes joined at the origin (R=G=B=0). Those axes form three edges of the cube. The cube has six faces defined by the following equations, assuming full scale is unity.

 R=0, R=1, G=0, G=1, B=0, B=1

Those  faces define the gamut of any RGB color space in its own color space.

Now imagine tipping the cube so that it rests on the vertex R=G=B=0, and the vertex R=G=B=1 is straight up from there. So the black point is at the bottom, the white point is at the top, and the luminance diagonal or gray axis, defined as R=G=B=x, where x is any number in the range [0,1], is straight up and down.

You can see that dark colors, near the black point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the black point. Light colors, near the white point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the white point.

The small gamuts near the black and white points map over roughly when the cube is transformed into a color space like CIEL*a*b*, yielding small chromaticity gamuts near the white and black points.

Better?

More to come when I get more time.

Jim

[digitaldog]

If you think of the Photoshop workflow it will make the issue clearer.  OK, I open the image as a raw SO in Photoshop. Fine, no problem, I can then add adjustment layers, apply a sharpening filter to the SO, crop, straighten, whatever.  Now I decide that the yellow saturation needs a tweak, so I double-click on the SO, do the edit in ACR and exit back into Photoshop.  And so on.

Now imagine that this scenario happened not now, but in 3 years time, when Lightroom/ACR has moved on to PV2016, say, so that my SO has all of its adjustments in the PV2016 context (the sliders may be different to PV2012, the effect of the sliders may be different, the demosaicing algorithm may have changed, affecting the look of the image etc.).  But now I decide I've had enough of CC, I don't want to continue to pay what has become an unacceptable annual fee for Photoshop, I am only using Photoshop occasionally by then ... whatever, basically I want to go back to the version of Photoshop I own, which is CS6.

I don't see this being any different in the results if you use an SO or not. That's my confusion with your issue. If you use a newer processing (PV 2016) that isn't available in the earlier PV 2012, going back reverts the appearance, how can it not? You have to either render the image using PV 2016 and stop the raw processing by your own doing (leaving the subscription and new featuers) OR continue to pay to use the new features.

I'm not clear how this is an SO issue. It's an issue with newer proprietary processing that by your own doing (stopping subscription), you lose. IOW, if we forget SO's, how is this issue any different if we were to discuss just LR 2 and LR 5.5? Wouldn't the same issue exist?

[Robert Ardill]

I guess I assumed too much in my post. Let me unpack the relationship of chromaticity and luminance in RGB spaces that I was trying to get at.

Any (real or imaginary) monitor-based RGB color space (called by most just an RGB color space) can be envisioned as a cube, with orthogonal red, green, and blue axes joined at the origin (R=G=B=0). Those axes form three edges of the cube. The cube has six faces defined by the following equations, assuming full scale is unity.

 R=0, R=1, G=0, G=1, B=0, B=1

Those  faces define the gamut of any RGB color space in its own color space.

Now imagine tipping the cube so that it rests on the vertex R=G=B=0, and the vertex R=G=B=1 is straight up from there. So the black point is at the bottom, the white point is at the top, and the luminance diagonal or gray axis, defined as R=G=B=x, where x is any number in the range [0,1], is straight up and down.

You can see that dark colors, near the black point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the black point. Light colors, near the white point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the white point.

The small gamuts near the black and white points map over roughly when the cube is transformed into a color space like CIEL*a*b*, yielding small chromaticity gamuts near the white and black points.

Better?

More to come when I get more time.

Jim

Thanks for the explanation Jim, but honestly, don't you think an apple provides a simpler explanation ... with the black at the bottom (it's in the shadows, after all) and the white is at the top (where the light is shining on it), and the fat bit in the middle which has all of these lovely reds and greens and yellows and oranges and purples ... which make you want to take a nice juicy bite ?

But, anyway, as you say, anything that has three reasonably linear coordinates will have that sort of shape, including Lab and XYZ (but not Lch, say, because its h is an angle, not an linear distance, so now we have a cylinder and not a cube, right?).

Robert
Robert

[Jim Kasson]

But, anyway, as you say, anything that has three reasonably linear coordinates will have that sort of shape, including Lab and XYZ (but not Lch, say, because its h is an angle, not an linear distance, so now we have a cylinder and not a cube, right?).

Robert, I'm not getting my point across if you think Lab has that cubical shape. The visible part of Lab is approximately conical, with the point at the bottom and the wide base at L* = 100, and the axis straight up and down.

Also, the luminance axis in Lab is x,0,0, not x,x,x, like it is in RGB.

Jim

[Robert Ardill]

I don't see this being any different in the results if you use an SO or not. That's my confusion with your issue. If you use a newer processing (PV 2016) that isn't available in the earlier PV 2012, going back reverts the appearance, how can it not? You have to either render the image using PV 2016 and stop the raw processing by your own doing (leaving the subscription and new featuers) OR continue to pay to use the new features.

I'm not clear how this is an SO issue. It's an issue with newer proprietary processing that by your own doing (stopping subscription), you lose. IOW, if we forget SO's, how is this issue any different if we were to discuss just LR 2 and LR 5.5? Wouldn't the same issue exist?

It isn't different except for one thing ... and that is that you can own Lightroom (at present) whereas you can no longer own the current version of Photoshop.  So if you have ANYTHING in Photoshop that is not backward compatible with CS6, you will clearly not be able to go back to CS6 without some potentially serious problems.  If your workflow includes the use of raw smart objects, as mine does, then you might be well advised not to use anything beyond PV2012 if you want to be able, at a future date, to go back to CS6.

If you don't use a raw smart object then the PV2012 issue doesn't arise,obviously. So then you've made the decision earlier on not to maintain the ability to edit your base raw image from Photoshop. if you do use raw SO, as long as you keep moving on with CC, no problem. Try to step back ... that's when you may (probably will) hit a problem.

If you used raw smart objects in any sort of regular manner and were concerned about getting locked in to CC you would see the problem.

Robert

[digitaldog]

IIf you used raw smart objects in any sort of regular manner and were concerned about getting locked in to CC you would see the problem.

That is true for any proprietary Adobe processing in terms of version accessibility. SO's are not unique.

[Robert Ardill]

Robert, I'm not getting my point across if you think Lab has that cubical shape. The visible part of Lab is approximately conical, with the point at the bottom and the wide base at L* = 100, and the axis straight up and down.

Also, the luminance axis in Lab is x,0,0, not x,x,x, like it is in RGB.

Jim

You're right ... I stand corrected, sort of.  The Lab coordinates are 3-dimensional, so there's nothing to prevent them representing a cube. The Lab gamut is another matter as that is constrained by the illuminant, and the standard observer, and it maps the visible spectrum within these constraints.

I haven't missed your point ... you made it clearly .

Robert

[papa v2.0]

 R=0, R=1, G=0, G=1, B=0, B=1
Those  faces define the gamut of any RGB color space in its own color space.

Hi, it defines the encoding space.

Iain

[Robert Ardill]

That is true for any proprietary Adobe processing in terms of version accessibility. SO's are not unique.

Andrew ... I'm not arguing that point. I agree!!

The reason I brought this up is that I, personally, don't want to get stuck with raw smart objects, or any other smart object or feature for that matter, that I can no longer process in CS6. My question was simply this: do you guys and gals agree that if I stick to PV2012 that I will be able to go back and edit the raw smart objects created in Lightroom xxx, ACR yyy, in Photoshop CC 20zz at a later stage, in Photoshop CS6.

It's not a theoretical, this is the same as that sort of discussion/question. It's 'how do I maintain raw smart object backwards compatibility with CS6?'.

It's clearly not a concern of yours since you don't use them, but in my workflow, which forms part of the discussion in this thread, I do clearly explain that it IS part of MY workflow.

At any rate, many thanks for your patience ... I think I've answered my own question as best as it can be answered at this point in time.

Robert

[Robert Ardill]

Hi, it defines the encoding space.

Iain

Very good, exaclty.

[digitaldog]

My question was simply this: do you guys and gals agree that if I stick to PV2012 that I will be able to go back and edit the raw smart objects created in Lightroom xxx, ACR yyy, in Photoshop CC 20zz at a later stage, in Photoshop CS6.

If you stick with CS6/ACR functionality I believe the answer is yes.
And it IS a concern for me, has been since Photoshop 1.09. Just not with SO's.

[Robert Ardill]

If you stick with CS6/ACR functionality I believe the answer is yes.
And it IS a concern for me, has been since Photoshop 1.09. Just not with SO's.

OK, cool.  Thanks Rodney.  I know I can be a bit trying on people's patience .

Robert

[Jim Kasson]

Maybe I shouldn't be using so many words to get my point across about the histogram. Maybe an example would help.

These two images have the same histogram.





Jim

[digitaldog]

If the editing could then be masked by the color map (more effect towards higher deltas, or edit selected range of deltas) it would be really fantastic.

We need overlay opacity so we can see what's under it with full control. We also need to swap colors so for example, if Red represents something and you're working on a red rose, you can change that overlay color.

[Robert Ardill]

We need overlay opacity so we can see what's under it with full control. We also need to swap colors so for example, if Red represents something and you're working on a red rose, you can change that overlay color.

I was thinking not of an overlay, but of a color-map as an additional panel below the histogram.  The problem with having the color-map over the image is that it makes it difficult to see the effect of the adjustments on the image (locally and also the effect of the local change on the color balance in the image). But I suppose the overlay could be toggled on and off ... and certainly being able to adjust the opacity would be very useful.

It should be possible to do this as a 3rd-party panel in Photoshop, I think.  It would have to be done by Adobe for Lightroom, I think.  Are you talking theoretically, like 'it would be nice if', or are you thinking of an implementation for Photoshop or talking to Adobe about a possible new feature?

Robert

[Robert Ardill]

Maybe I shouldn't be using so many words to get my point across about the histogram. Maybe an example would help.

These two images have the same histogram.

Jim

Hi Jim ... you're still leaving me behind, I'm afraid.  Are you referring to your previous post where you say: "Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images."?  So that gray, for example, will give the same histogram peak as its RGB components separated out, as you show.

It would be useful to explain what a color histogram actually is (which I assume is one of the things you are attempting to do?).  My understanding is that its essentially a graphical representation of the tonal range of the image.  As such, its main use is to give us an idea about things like shadow and highlight clipping, whether the image is under-exposed or over-exposed ... that sort of thing.  It isn't intended to show whether or not parts of the image are out of gamut (how could it? the image will never be OOG in its own color space), and so we shouldn't use it for that purpose (I can't imagine that anyone would).

So I'm not sure what your point is .

Robert