Does anyone know what at lstar 50 workflow is (perhaps lstar-rgb = eicrgb)?

[BriansT]

Does anyone know what an lstar 50 workflow is?

[Erland]

I can't say I've heard anything about that particular workflow.
However, I have recently started working with scanning my 35mm film. And one workflow I tried, and made my first choice was scanning a raw, which comes out from the scanner with a gamma of 1.0, and apply a custom made (by me) scanner color space with a gamma of 1.0 instead of the usual 2.2-ish. If he is scanning the darkroom print with a scanner using something similar workflow, it could mean he gets a linear trc, and then can match the tones in the print using a densitometer with the scanned version in say photoshop?
Just a thought really.

[digitaldog]

My advise is to stay away from this potential rabbit hole! Hard to say what exact rabbit hole in terms of Lstar this printer is referring to as he's saying so little. Where? The editing space, the output space, the scanner color space defined by it's profile? Just forget it, in color managed workflows, about the last thing you need to concern yourself with is the gamma encoding, linear or not. This was a big topic with the Europe color geeks awhile back but they failed to produce any peer review pieces to back it up after a request to do so on the ColorSync list. Gamma encoding flavor of the month, not much more.

[bjanes]

My advise is to stay away from this potential rabbit hole! Hard to say what exact rabbit hole in terms of Lstar this printer is referring to as he's saying so little. Where? The editing space, the output space, the scanner color space defined by it's profile? Just forget it, in color managed workflows, about the last thing you need to concern yourself with is the gamma encoding, linear or not. This was a big topic with the Europe color geeks awhile back but they failed to produce any peer review pieces to back it up after a request to do so on the ColorSync list. Gamma encoding flavor of the month, not much more.

If one is working in an 8 bit space, the tone curve, gamma or L*, does make a small difference compared to gamma 2.2 as Bruce Lindbloom explains in his writeup for his BetaRGB (see the graph on the here link). Since L* is perceptually uniform, it offers slightly improved quantization over gamma 2.2. Linear gamma is far from ideal, since it has two few steps in the shadows and wastes levels in the highlights. With 16 bit quantization, is less of an issue, and it is nonexistent in HDR linear 32 bit encodings.

eciRGB is designed for the print and publishing industry and its gamut (slightly larger than AdobeRGB) covers what can be output on a printing press. However, most of us on this forum are using wide gamut inkjet printers and the gamut of eciRGB may be insufficient for these printers, but that of ProPhotoRGB will cover these devices. The 1.8 gamma is not ideal, but with 16 bit encoding quantization is not an issue.

Bill

[digitaldog]

Since L* is perceptually uniform, it offers slightly improved quantization over gamma 2.2. Linear gamma is far from ideal, since it has two few steps in the shadows and wastes levels in the highlights. With 16 bit quantization, is less of an issue, and it is nonexistent in HDR linear 32 bit encodings.
Bill

Best post I've seen yet on the subject:

Subject:   Re: [Icc_users] L* workingspaces and L* output calibration
Date Received:   Tuesday, March 11, 2008 8:46:58 PM
Date Sent:   Tuesday, March 11, 2008 8:38:07 PM
From:   Lars Borg <borg@adobe.com>
L* is great if you're making copies. However, in most other
scenarios, L* out is vastly different from L* in.  And when L* out is
different from L* in, an L* encoding is very inappropriate as
illustrated below.

Let me provide an example for video. Let's say you have a Macbeth
chart. On set, the six gray patches would measure around  L* 96, 81,
66, 51, 36, 21.

Assuming the camera is Rec.709 compliant, using a 16-235 digital
encoding, and the camera is set for the exposure of the Macbeth
chart, the video RGB values would be 224,183,145,109,76,46.

On a reference HD TV monitor they should reproduce at L* 95.5, 78.7,
62.2, 45.8, 29.6, 13.6.
If say 2% flare is present on the monitor (for example at home), the
projected values would be different again, here: 96.3, 79.9, 63.8,
48.4, 34.1, 22.5.

As you can see, L* out is clearly not the same as L* in.
Except for copiers, a system gamma greater than 1 is a required
feature for image reproduction systems aiming to please human eyes.
For example, film still photography has a much higher system gamma
than video.

Now, if you want an L* encoding for the video, which set of values
would you use:
96, 81, 66, 51, 36, 21 or
95.5, 78.7, 62.2, 45.8, 29.6, 13.6?
Either is wrong, when used in the wrong context.
If I need to restore the scene colorimetry for visual effects work, I
need 96, 81, 66, 51, 36, 21.
If I need to re-encode the HD TV monitor image for another device,
say a DVD, I need 95.5, 78.7, 62.2, 45.8, 29.6, 13.6.

In this context, using an L* encoding would be utterly confusing due
to the lack of common values for the same patches.  (Like using US
Dollars in Canada.)
Video solves this by not encoding in L*. (Admittedly, video encoding
is still somewhat confusing. Ask Charles Poynton.)

When cameras, video encoders, DVDs, computer displays, TV monitors,
DLPs, printers, etc., are not used for making exact copies, but
rather for the more common purpose of pleasing rendering, the L*
encoding is inappropriate as it will be a main source of confusion.

Are you planning to encode CMYK in L*, too?

Lars

[bjanes]

Best post I've seen yet on the subject:

That is interesting, but wouldn't the same considerations apply to gamma 2.2 encoding? Gamma 2.2 in may not be gamma 2.2 out due to flare and other considerations.

[digitaldog]

That is interesting, but wouldn't the same considerations apply to gamma 2.2 encoding?

It probably does but it doesn't make the Lstar route any better.

[digitaldog]

Icc_users mailing list
Icc_users@lists.color.org
http://lists.color.org/mailman/listinfo/icc_users