File naming conventions?

[DanK]

I'm confused.

So do I understand right that the issue isn't really more flexibility; the issue is fidelity when changing from RGB space to the Lab color space?

Either way, with ACR or LR, one works in RGB, if I'm right, and and both have access to every pixel the camera recorded. After all, they are the same underlying processing engine. With ACR, the software converts to Lab while moving the image into Photoshop, whereas with Lightroom, one moves it into Photoshop and then converts to Lab. And people are telling you that the former does a better job of mapping from RGB space to Lab space then the latter? It would be hard to test this, but I would be willing to place a sizable wager that it makes no perceptable difference.

[Manfred M]

Dan - it is two things, a simplified workflow (sort of) and and deeper (potential) pool of colour data to work with.

A decent modern digital camera is capable of capturing any colour a human can see, which for arguments sake is the CIELAB 1976 colour space. All of our devices (excluding the colour printing process) are RGB devices, from cameras, to screens, to projectors. The photo printer industry even fools us into believing that their devices are RGB ones, so to a large extent most photographers think in RGB.

The computer types have come up with a number of ways of representing RGB and from a photography standpoint, there are currently four commonly used RGB colour models; sRGB, DCI-P3 (the approach Apple uses on its most recent lines of displays), Adobe RGB and ProPhoto RGB. There are many others, but they are not something we tend to use in photography.

One advantage touted by Lightroom (and other parametric editor) fans is that those tools have access to every single colour captured by the camera. Photoshop and other pixel based editors need to work on image data, so they must have a colour space assigned to them in order for the software to work, so by converting the raw data into an image file, some of the data could be discarded. The amount is dependent on both the colour content of the capture and the range of the colour space that has been used.

The only work around that I know of is to use the L*a*b* colour space that ACR exports to natively. Lightroom (and all of the other mainstream raw processors I've looked at) can only export to one of the four RGB colour models that I listed. If one wants to work in the L*a*b* colour space using the conversion in Photoshop means we are starting with some degree of data loss by going from RGB to L*a*b*.

If we work with ACR, then we do a native conversion of the raw data and no colour loss.

I hope this makes sense...


As an aside plugins and a lot of the filters that ship with Photoshop cannot be used with the L*a*b* (or CYMK colour spaces).

[John Pilkington]

Well, thank you Manfred and Dan. The later parts of this discussion are way beyond me but I'm glad you have found this thread useful. Thanks for sharing accounts of your workflow. Agreed, there is no one correct way but it certainly helps to know what options are available.

I have a great deal of sympathy with Manfred's approach, retaining a sound file and directory structure and so not relying entirley on a catalog - keywording seems to me important, but without knowledge of the underlying file structures leaves me feeling as though I'm working in the dark somehow. I like to know where things actually are on my system.

All this feeds nicely into my original thread regarding whether to stick with Adobe or break free. The question is still open for me, although I'm leaning towards using particular apps for particular purposes instead of the global Adobe approach.

[DanK]

John,

One more detail: LR uses the directory structure on your hard drive. What you see in the library panel is identical to the directory structure you will see in a file manager. LR simply overlays additional functions on the directory structure. That's why I always upload photos to a folder with a date and name before importing into Lightroom. The one limit is that if you want to change that structure, you have to do it in LR.

Dan

[DanK]

Manfred,

This is both hijacking the thread and going beyond what I know, but...

Adobe is fairly closed-mouthed about the internal workings of its raw processor, but here is what I have gleaned from various sources, Adobe when possible. Let me know if you think any of this is incorrect.

1. Adobe has a single raw processing engine, onto which they put two front ends, LR and ACR.
2. The internal working space of this raw processing engine is called Linear ProPhoto RGB, which is basically ProPhoto but with a linear tonal response curve.
3. For purposes of viewing and creating a histogram, this is converted to a proprietary version of ProPhoto called "Melissa".

If this is all correct, the fork in the road comes at the point of moving the image into Photoshop. ACR allows you to convert from Linear ProPhoto to Lab in the process of creating the Photoshop base layer. Lightroom does not: it will create the base layer in whatever the Photoshop working space is, presumably ProPhoto, and requires that you convert this to Lab as a subsequent step.

If all this is correct, can it really make an appreciable difference?

BTW, totally off topic, it seems to me that people have two main reasons for converting from ProPhoto to Lab in Photoshop. One is to separate tonality adjustments from color adjustments. The second is the flip side: to be able to manipulate color separately from tonality, using the a and b axes rather than RGB. I don't do the second, for the most part. I find it awkward to work on the a and b axes, and if one simply wants to remove tonality from color adjustments, one can use a color blend in RGB space. I do the former a lot because I often don't want tonality adjustments to affect saturation. However, I find it easier to do this with a luminosity blend in RGB space. That avoids two problems: the loss of information that occurs when switching from RGB to Lab or vice versa (losing the layers within the old color space), and filters or plugins that don't work in Lab.

But this last is just a matter of preference. I'm not suggesting it's better, just explaining why I find it easier.

Dan

[Manfred M]

Manfred,

This is both hijacking the thread and going beyond what I know, but...

Adobe is fairly closed-mouthed about the internal workings of its raw processor, but here is what I have gleaned from various sources, Adobe when possible. Let me know if you think any of this is incorrect.

1. Adobe has a single raw processing engine, onto which they put two front ends, LR and ACR.
2. The internal working space of this raw processing engine is called Linear ProPhoto RGB, which is basically ProPhoto but with a linear tonal response curve.
3. For purposes of viewing and creating a histogram, this is converted to a proprietary version of ProPhoto called "Melissa".

If this is all correct, the fork in the road comes at the point of moving the image into Photoshop. ACR allows you to convert from Linear ProPhoto to Lab in the process of creating the Photoshop base layer. Lightroom does not: it will create the base layer in whatever the Photoshop working space is, presumably ProPhoto, and requires that you convert this to Lab as a subsequent step.

If all this is correct, can it really make an appreciable difference?

BTW, totally off topic, it seems to me that people have two main reasons for converting from ProPhoto to Lab in Photoshop. One is to separate tonality adjustments from color adjustments. The second is the flip side: to be able to manipulate color separately from tonality, using the a and b axes rather than RGB. I don't do the second, for the most part. I find it awkward to work on the a and b axes, and if one simply wants to remove tonality from color adjustments, one can use a color blend in RGB space. I do the former a lot because I often don't want tonality adjustments to affect saturation. However, I find it easier to do this with a luminosity blend in RGB space. That avoids two problems: the loss of information that occurs when switching from RGB to Lab or vice versa (losing the layers within the old color space), and filters or plugins that don't work in Lab.

But this last is just a matter of preference. I'm not suggesting it's better, just explaining why I find it easier.

Dan

Close in some regards; Linear ProPhoto RGB is "Melissa". It has a gamma curve of 1.0 rather the spec ProPhoto RGB (a.k.a. ROMM RGB) spec of 1.8. Adobe RGB uses a gamma of 2.2 and sRGB is an oddball where the mid-tones are showing characteristics of a 2.2.gamma while the shadow and highlight regions are closer to being linear. There are historical reasons for these, primarily linked to the technology of the time and the industries that were being served. The 2.2 value has roots in the broadcast (and later photography) and the 1.8 was used in the printing press world. The default gamma in Apple computers was 1.8 until about 10 years ago, when they switched to 2.2.

What we do know is that Lightroom was designed for photographers and Photoshop / Adobe Camera Raw is aimed at the graphic arts industry. If you look at the Adobe Color Picker, they clearly indicate support for four different colour models in Photoshop; RGB, L*a*b*, CMYK and HSB. That suggests to me that other colour models are natively supported, otherwise there would have to be some input regarding rendering intent for OOG issues. While there have been conversations regarding Melissa with respect to Lightroom, I have never seen any credible comments that this also applies to Photoshop / ACR. What we do know is that Photoshop has supported CMYK for a very long time. L*a*b*, I don't know as I had only started using it in my usual workflow over the past few years.

The main reason I use the L*a*b* colour space is speed when dodging and burning. I use the L channel and don't need to flip around from normal to luminosity blending mode, so I save a bit of time and error (forgetting to change blending modes).

My comments about native support of L*a*b* comes from some veteran retouchers who have extensive contacts in the industry. I trust them based on their experience, but they could be wrong.

[DanK]

maybe. The color picker having a Lab option doesn't indicate that ACR isn't working in another color space. Photoshop offers the same Lab option even if you have the working space set to Adobe RGB or ProPhoto RGB. Lightroom offers the option of using Lab for the histogram, even though it has an RGB working space, and if you have it set to Lab, those are the values shown for the equivalents of the color picker (e.g., the targeted adjustment tool in the color panel). And ACR Adobe refers to the menu choices you pointed to as "output" choices.

I find it very frustrating that Adobe makes it so difficult to pin this sort of thing down. I can see why they want to keep a lot of things proprietary, but identifying the working space needn't be one of them.

[DanK]

Here's Andrew Rodney's take on this. Doesn't fully answer the issues here, but answers some.
https://www.photo.net/discuss/thread.../#post-5931404

[Manfred M]

Thanks Dan - Rodney knows his stuff and I assume he still has a lot of contacts at Adobe to validate these things.

The real issue is that we don't know what is happening internally; Rodney does confirm that there are a number of different algorithms operating inside the software for different purposes. It also seems that Adobe is not being 100% honest that ACR and the LR Develop Module engines are identical (although to be frank, they have never quite defined what that means).

The other place I have noticed differences in the past was with the translation between CMYK and RGB, especially when ProPhoto was the colour space being used. In the past there were also some issues with the print engine with 16-bit data was output that did not occur with 8-bit output. Again I have not noticed this issue over the past 4 or 5 years, so this could be another bug that has been repaired.

[DanK]

I agree; it’s frustrating not to know more. I never use CMYK, so I haven’t run into that issue.

For me, the biggest difference between the two is simply workflow.


Sent from my iPad using Tapatalk

[xpatUSA]

Close in some regards; Linear ProPhoto RGB is "Melissa".

Sorry, Manfred, the statement is not quite correct.

'Melissa' is Adobe's bastardized version of ProPhoto RGB which was previously known as Kodak's ROMM; in other words, ProPhoto came first.

http://kronometric.org/phot/color/Kodak%20ROMM.pdf

Therefore, I would say that 'Melissa' is not Linear ProPhoto RGB.

[Manfred M]

Sorry, Manfred, the statement is not quite correct.

'Melissa' is Adobe's bastardized version of Kodak ROMM which is also known as ProPhoto; in other words, ProPhoto came first.

http://kronometric.org/phot/color/Kodak%20ROMM.pdf
.

You misunderstood what I have written Ted. Adobe adopted a version of ProPhoto RGB / Kodak ROMM (which has a gamma curve of 1.8) with a version with a gamma curve of 1 (i.e. linear gamma). This is sometimes referred to as "Melissa".

When Dan writes about "Linear ProPhot RGB" and "Melissa", so far as I understand it, they are both the same.

[DanK]

You misunderstood what I have written Ted. Adobe adopted a version of ProPhoto RGB / Kodak ROMM (which has a gamma curve of 1.8) with a version with a gamma curve of 1 (i.e. linear gamma). This is sometimes referred to as "Melissa".

When Dan writes about "Linear ProPhot RGB" and "Melissa", so far as I understand it, they are both the same.

That's not what Andrew wrote, and it's not what I have read elsewhere. What Andrew wrote is:

MelissaRGB is ProPhoto RGB primaries (gamut) with a 2.2 TRC like sRGB and is only used for the Histogram.
Internal processing color space is ProPhoto RGB primaries, 1.0 TRC and has no name.

[xpatUSA]

You misunderstood what I have written Ted. Adobe adopted a version of ProPhoto RGB / Kodak ROMM (which has a gamma curve of 1.8) with a version with a gamma curve of 1 (i.e. linear gamma). This is sometimes referred to as "Melissa".

When Dan writes about "Linear ProPhoto RGB" and "Melissa", so far as I understand it, they are both the same.

Melissa's white reference is D65 and ProPhoto's is D50. Melissa's working gamma is 1 and ProPhoto's is 1.8 with a linear portion.

So, they are not "both the same", IMHO. I'll allow that they might be vaguely similar ...

Interestingly, reading through the link I posted earlier, I found that Adobe was already messing up ProPhoto (Kodak ROMM) in Photoshop no less than 21 years ago - see Page 5.

May I remind you of this post:

Color management in Photoshop

et subs.

[xpatUSA]

... BTW, totally off topic, it seems to me that people have two main reasons for converting from ProPhoto to Lab in Photoshop. One is to separate tonality adjustments from color adjustments. The second is the flip side: to be able to manipulate color separately from tonality, using the a and b axes rather than RGB. I don't do the second, for the most part. I find it awkward to work on the a and b axes, and if one simply wants to remove tonality from color adjustments, one can use a color blend in RGB space.

Just for interest, in the GIMP one can decompose an image into it's components such L*a*b*. But, one such option is to decompose into L*Ch (lightness, chroma, hue) which is a little more intuitive than messing with the a*b* axes. Here's Daniel's recent subject of discussion with only the C (chroma) changed:



All I did was to crank C (chroma) from 0 to 40 in Levels Out, then recompose.

I left the L* and h layers as-is ... image is of course exaggerated for the purpose of illustration.

[xpatUSA]

Perhaps the least interesting aspect of post processing is cataloging and generally keeping track of one's images; what, from replies to my previous post (Breaking free from Adobe?) I now know is conveniently referred to as Digital Asset Management. Software can help, of course, but fundamentally it seems sensible to organise and name the image files in a meaningful way. Would anybody be prepared to share comments on this?

I disagree, John.

"Software can help" is understating the issue. Serious Digital Asset Management should not rely on file names or their locations on a drive.

I strongly suggest that you get software which can at least add keywords to image files and has a good search engine to look for them and present them in a catalog view for browsing, no matter where they are located on your drive.

My current preference is XnView MP which has the best search engine I've seen. It can look for exif entries, IPTC entries, XMP entries and, yes, even filenames and, most importantly, it can look in all sub-folders of your starting point.

It's free ... you could at least give it a try ...

If you prefer to go through all your thousands of files re-naming them and moving them around between folders and coping with the inevitable dupes, then by all means go ahead.

[xpatUSA]

...
A decent modern digital camera is capable of capturing any colour a human can see, which for arguments sake is the CIELAB 1976 colour space.

Apropos of which an older paper explores the capture capability of cameras beyond the 1931 xy diagram.



I've got the paper somewhere which explains the target dots.

Some clarification or maybe further confusion is offered by the following about the tortuous journey from sensor capture to Adobe's review image here:

http://kronometric.org/phot/color/sc...ges%20RIMM.htm

Heavy going ... ICC stuff is never easy ... but please at least read the Introduction which does have a bearing on all this "Melissa" and color space talk, I reckon.

[John Pilkington]

I disagree, John.

"Software can help" is understating the issue. Serious Digital Asset Management should not rely on file names or their locations on a drive.

I strongly suggest that you get software which can at least add keywords to image files and has a good search engine to look for them and present them in a catalog view for browsing, no matter where they are located on your drive.

My current preference is XnView MP which has the best search engine I've seen. It can look for exif entries, IPTC entries, XMP entries and, yes, even filenames and, most importantly, it can look in all sub-folders of your starting point.

It's free ... you could at least give it a try ...

If you prefer to go through all your thousands files re-naming them and moving them around between folders and coping with the inevitable dupes, then by all means go ahead.

Thanks for your comments, Ted. Yes, XnView MP is very much on my list of DAM software, as is PhotoSupreme (the Lite version is also free). I don't think we have any fundamental disagreement about the value of a good DAM; a nice simple and consistent underlying file structure can be helpful too.

I mentioned ThumbsPlus in my original post. I'm not sure that it is supported any more, and anyway seems to be superseded by more modern apps, but one of the things I liked about it was direct access to the database by SQL query.

Hey guys, keep up the off-topic discussion of color space it's educational.

Cheers,

John

[xpatUSA]

Thanks for your comments, Ted. Yes, XnView MP is very much on my list of DAM software, as is PhotoSupreme (the Lite version is also free). I don't think we have any fundamental disagreement about the value of a good DAM; a nice simple and consistent underlying file structure can be helpful too.

Agreed; In terms of what stuff is in what folders, my HD is a mess having grown thus over a couple of decades.

I mentioned ThumbsPlus in my original post. I'm not sure that it is supported any more, and anyway seems to be superseded by more modern apps, but one of the things I liked about it was direct access to the database by SQL query.

Indeed, the search options provided by many photographic apps are a joke compared to a proper query language. You will find that XnView MP (not the previous XnView) is pretty good, IMO.

Hey guys, keep up the off-topic discussion of color space it's educational.