Film Negative Invert and Processing in L* Gamma FAQ

When you transform it to some large color space like ProPhotoRGB and check histograms - it usually looks ok and also unclipped.

But if you transform same raw source to tiny sRGB color space - you got strong clipping.

The raw is in neither color space for one. But the bigger issue is, the ProPhoto RGB container is larger than the sRGB container, and large enough to provide RGB values that are not actual colors. But also more saturated actual colors than sRGB so clipping from either is to be expected. One is invisible.

Leave sRGB as an output color space for the web and mobile devices (that may not understand color management). Otherwise sRGB is rather useless.

The raw is in neither color space for one.

Ok, i mean here "raw" as debayered to RGB but non color managed yet image source.

Leave sRGB as an output color space for the web and mobile devices (that may not understand color management). Otherwise sRGB is rather useless.

Sure sRGB as an output color space for the web. sRGB was shown here just for test purposes to see difference in exposure clipping in more obvious way.

Ok, i mean here "raw" as debayered to RGB but non color managed yet image source.

That is in a known RGB source or it couldn't become RGB in the 2nd place.

Here is also side by side comparison example how custom made camera input profile works and how it helps to fix problems with low quality backlight.

Examples processed only with Invert + AutoLevels. No grey point adjustment or any sort of "snap neutral midtones" used here.

As usual, these are extreme examples from some point of view. I would never suggest anyone to use basic low quality LEDs as film scans backlight.

And here are with Grey Point picked from same area in both images:

Explanation:

There is an original linear raw data that was monitored by RAW histograms and was shoot unclipped.

The explanation is more like:

Unaligned histograms occupy different sections of whatever tone curve is used by the working colour-space. Therefore they have different lengths and tonal relationships - 'crossed curves' in old photographic parlance.

Simply stretching those histograms to the same length using levels doesn't adjust their shadow-highlight imbalance in relation to each other.

Whereas optically, or digitally aligning those histograms (through use of RAW colour-temperature and tint) goes a long way toward reducing those tone-curve induced errors. It also prevents the red or blue histograms being pushed beyond the exposure limits. As is perfectly shown above by your unaligned red histogram disappearing into the overexposure region.

However, film being film, those histograms were never going to fully align and match in the first place - see those maker's characteristic curves I posted earlier.

In short, there's no fixed process or preset manipulation you can apply that will fully correct for the different dyes, sensitivity curves and masking of all types of colour negative film. Scanner makers know this, which is why there are a multiplicity of inbuilt profiles in their software.

Example of above misalignment causing a dominant colour.

Here's a negative copied at the light-source white balance, together with its RAW histogram -

Note how the RGB histograms are separated.

Now with a +1 exposure adjustment -

Not only do the histograms change position, but their relative height and shape changes too.

Similarly with a -1 stop exposure adjustment.

But by manipulating the white balance and tint, we can bring the histograms onto (what will be) the same section of working-space tone curve.

And after a simple invert, auto-color and tone curve adjustment, we get this -

OTOH, applying the same actions to the unaligned histogram (mask uncompensated) version, we get this -

Now we'd have to fiddle about in the Hue/Saturation tool to get rid of the luminous greens.

The above both used AdobeRGB as the working space. Exported as sRGB to show here.

Here's a colour checker card shot on the same roll of film and given the same mask-compensation treatment in RAW. This time with some help from a blue gel filter on the copier light source.

However, the adjustment to CT and tint is quite demanding of precision. In the same way that a small change in the enlarger filter pack used to make a very visible difference to wet-printed colour prints. And some film types still need a hue and/or saturation adjustment - usually to the red or yellow channel - to compensate for dye or mask differences. It's more an art than a science.

Just FWIW. Here's my final take on the passion flower picture above, with some minor additional tweaks.

"applying the same actions to the unaligned histogram (mask uncompensated) version, we get this"

You just got saturation clipping here because some colors don't fit to sRGB or AdobeRGB color space.

But when you adjust WB and align channels your extreme colors start to fit better to those tiny sRGB or AdobeRGB color spaces and so no clipping in final image.

Problem in Lightroom - it is not too clear sometimes how exact it use color management. It do all processing natively inside ProPhotoRGB but same as other raw editors it show histograms clipping level based on color space selected in export options.

"Not only do the histograms change position, but their relative height and shape changes too."

This is because Lightroom can't remove custom contrast camera curve (actually it can but need some hack for this), so exported images are always distorted with some sort of random additional contrast from start. This may add additional artifacts during invert and autolevels.

By the way, are you Invert and AutoLevels directly in Lightroom or later in Photoshop?

It's more an art than a science only when instead of searching tech mistakes in color management, people attempt to adjust and fix those mistakes during additional color correction.

If you like to share raw source of that flower here, i can show you that it is easy to get unaligned histogram (mask uncompensated) and same time have no any saturation clipping. And same time in this scenario colors will look better from start because relations between colors will not be distorted by some random WB adjustmnent.

By the way, it appears that there IS a way to export source image without additional build-in contrast curve from Lightroom/ACR! Just switch to Process Version 2003 or 2010 and reset all sliders to 0. Lightroom/ACR also can do color management, so you may export your scan directly to ProPhotoRGB with L* gamma or to any other color space/gamma you like.

Also here is another side by example why it is a bad idea to randomly align channels or "remove orange mask" by adjusting WB in RAW. Relations between original colors juts became distorted and you will get over/under saturation and hue shifts.

To exclude variations this is example made with original factory Fujifilm X-E4 camera input profile. Due low quality LEDs both test examples look ugly, but colors in image with orange mask removed in RAW looks broken even more.

Example of above misalignment causing a dominant colour.

 

Here's a negative copied at the light-source white balance, together with its RAW histogram -

[ATTACH=full]1385045[/ATTACH]

What raw Histogram? Looks like ACR to me; not raw. NO Adobe product provides the user with a raw Histogram.

Lightroom/ACR also can do color management, so you may export your scan directly to ProPhotoRGB with L* gamma or to any other color space/gamma you like.

Considering all the internal RGB color space processing IS ProPhoto RGB primaries with a linear TRC, doing this is pointless.

“There seems to be some perverse human characteristic that likes to make easy things difficult.” -Warren Buffett

When I hear somebody say, 'Color management is difficult to understand' I am always tempted to ask, 'Compared to what?'

You just got saturation clipping here because some colors don't fit to sRGB or AdobeRGB color space.

No. I didn't. You can clearly see that the camera exposure RGB histograms don't go into saturation.

And even if they were 'invisibly' saturated, how is that to be overcome?

Maybe by aligning the histograms in the first place? Just as I've constantly suggested.

What raw Histogram? Looks like ACR to me; not raw. NO Adobe product provides the user with a raw Histogram.

Yes, my bad. I meant to say the histograms shown by the RAW converter. But the explanation was already quite wordy. ACR presumably shows the histograms as they'll be after export into the target space - AdobeRGB in this case.

Considering all the internal RGB color space processing IS ProPhoto RGB primaries with a linear TRC, doing this is pointless.

Linear?

The spec for ProphotoRGB shows a gamma 1.8 curve sitting on top of a tiny linear slope.

What am I missing?

So rodeo_joe|1 miss info about what color space was selected in export options there.

No again. I just skipped what I thought was a needless explanation

Can you provide raw example?

You just do something wrong somewhere in your workflow that cause that strange saturation. I really have no idea why it looks like this in your example.

Here is link to my RAW file example, if someone want to play with it:

X-E4_DSF0397 TEST.RAF

The idea of this thread was to provide well behaved and stable starting point and explain the sources of all possible variables and problems here. If things done technically correct - image should look nice from start.

Linear?

The spec for ProphotoRGB shows a gamma 1.8 curve sitting on top of a tiny linear slope.

What am I missing?

It was an official Kodak specs for ICC profile named "ProphotoRGB". It consists of ProphotoRGB primaries and gamma 1.8.

Some apps just use ProphotoRGB primaries and different gamma.

For example Lightroom/ACR for processing transform internally debayered data to ProphotoRGB primaries with linear gamma transformed in the end to sRGB gamma i guess (formally they name this Melissa RGB)

Or for example in my workflow i use ProphotoRGB primaries with L* gamma.

It is ok to use any custom combination of primaries (color space) and gamma for your needs.

OK.

Explain this.

Both passion flower examples above were processed from the same Sony camera RAW file. Shot at light-source White Balance.

If the unadjusted version had saturated and out-of-gamut colours, as you've suggested. Then how come the histogram-aligned version (from the exact same file) did not?

Same TRC and colour space used for import, and same procedure applied to both.

My 'get rid of the mask' method works consistently, and with a minimal amount of afterwork needed. Photoshop's Autocolor produces a good result in most cases. No need to fart about dragging sliders to where it looks as if the histograms end.

However, I'll freely admit that some films don't co-operate. Whether that's because of processing variations, dye differences or age-fading I don't know. And really don't care. If a hue rotation or saturation adjustment gets me to an acceptable result, then that's what I'll use.

What I refuse to believe is that you've come up with some magic and foolproof formula that works with just a couple of mouse-clicks to get perfect colour from every type of colour negative, every time.

Come clean. How long does it take you to process one frame?

Because we can all get a great result given all day to achieve it.

When it goes to negative processing it is about:

Subjective compare

Understanding what variable cause changes in final look

Understanding was it caused by a technical mistake or was it just something related to actual film look.

A lot of things are subjective and a lot of conclusions are up to personal tech level. Sometimes on some level conclusions may look logical but they appears incorrect in reality.

Film produce huge amount of saturation, so it require really large digital color space to work normally. AdobeRGB is rather small and can't fit film colors without clipping.

Explain this.

Both passion flower examples above were processed from the same Sony camera RAW file. Shot at light-source White Balance.

- Processing in Lightroom is incorrect. With normal processing in Lightroom/ACR it is impossible to output "flat" uncorercted tiff file usable for proper invert and processing.

What I refuse to believe is that you've come up with some magic and foolproof formula that works with just a couple of mouse-clicks to get perfect colour from every type of colour negative, every time.

- You just refuse to test, compare, learn and try technically correct options. You also post huge amount of incorrect info and incorrect conclusions based on this info. This only confuses people.

Come clean. How long does it take you to process one frame?

- Batch convert from raw to tiff. One click on action + few mouse scrolls + grey point pick + contrast LUT. I already posted videos here.

Because we can all get a great result given all day to achieve it.

If some photos with some specific settings look ok by luck it doesn't mean that things are ok.

If the unadjusted version had saturated and out-of-gamut colours, as you've suggested. Then how come the histogram-aligned version (from the exact same file) did not?

- When you "align" channels you formally also reduce exposure a lot. This protects colors from clipping in tiny AdobeRGB space. "align" channels is a bad way to do because it is distort original relations between colors and image look incorrect after invert. Depending of input profile quality, film colors complexity and saturation amount difference may be visible more or less.

Unadjusted version just brighter in summary and so produce clipping in tiny AdobeRGB space. Some tiny amount of colors may be clipped, but it may be not too visible on low resolution histogram. This is why it is always better to monitor clipping by film frame, but not by actual image.

What I refuse to believe is that you've come up with some magic and foolproof formula that works with just a couple of mouse-clicks to get perfect colour from every type of colour negative, every time.

- I provided workflow and all possible explanations here. Test it, try it, use it or don't. I really don't care. some magic LOL

Yes, my bad. I meant to say the histograms shown by the RAW converter. But the explanation was already quite wordy. ACR presumably shows the histograms as they'll be after export into the target space - AdobeRGB in this case.

Wordy perhaps, incorrect indeed. So for both our audiences, let's get the colorimetric facts defined correctly no matter the wordy-ness ;). First: Adobe RGB (1998), nope. Whatever RGB color space is selected in Workflow Options. And the underlying color processing is always done in ProPhoto RGB with a linear TRC. Always. Then maybe you convert to another colors space from there.

Linear?

TRC=1.0 which IS the case with the underlying color space for raw processing in ACR/LR.

The spec for ProphotoRGB shows a gamma 1.8 curve sitting on top of a tiny linear slope.

What am I missing?

No again. I just skipped what I thought was a needless explanation

First, what you're missing is the TRC of the processing color space and then you're missing what the Histogram shows based on whatever workflow options is setup by the user and those two are not the same. Those who read past that can see how the product(s) actually work in terms of the color space, TRC of that color space and the display of the Histogram. NONE of which show us raw data. ProPhoto RGB does not have a "tiny linear slop"; its got a 1.8 gamma (which differs slightly from a TRC). sRGB has a TRC. ProPhoto RGB as a gamma curve.

What you feel is needless amounts to text that isn't correct and to those who may not know you feel a correct explanation of what's actually happening and not at all needless and deserve the facts about how this all actually works.

It was an official Kodak specs for ICC profile named "ProphotoRGB". It consists of ProphotoRGB primaries and gamma 1.8.

ONE space created by Kodak (is actually named ProPhoto RGB***) has a TRC of 1.8. They also specified a similar space, the only difference being the TRC: it's called ROMM RGB/ISO 22028-2:2013. Look it up.

https://www.color.org/chardata/rgb/rommrgb.xalter

And this is what's used in LR/ACR for processing.

Of course, it's super easy to create a ROMM RGB profile (in Photoshop) but again, kind of pointless to do so expect for the color geeks for sake of curiosity.

- Processing in Lightroom is incorrect. With normal processing in Lightroom/ACR it is impossible to output "flat" uncorercted tiff file usable for proper invert and processing.

Nope, you simply haven't learned how to render output referred** data from there!

http://www.color.org/scene-referred.xalter

** http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf

- When you "align" channels you formally also reduce exposure a lot.

No! You don't affect exposure whatsoever. Exposure only takes place at image capture; the result of how much light stikes a sesnor due to two and only two attributes: Aperture and Shutter. There may be a difference in brightness! That's the word you are missing. This has absolutely nothing to do with exposure.

IF you up the so called "Exposure" slider in LR/ACR, you are not affecting exposure at all. You are altering brightness.

***As the Chinese proverb says: "The first step towards genius is calling things by their proper name." Exposure isn't it in any raw processor sir. That takes place at capture (and a reason why shooting raw+JPEG is harmful to one of those two images in terms of data quality).

Film produce huge amount of saturation, so it require really large digital color space to work normally.

Evidence for that?

Colour negative dyes are actually quite poor and unsaturated. A glance at a 'neutralised' colour neg will tell you that.

Where the over-saturation comes from is the contrast boost that's needed to turn a weak negative image into a strong self-luminous (on screen) digital image. This contrast was intended to come from the steep 'gamma' of colour printing paper, which also had imperfect dyes in it.

Both the cyan and magenta dyes suffer from yellow bleed, which is why the yellow-magenta positive mask was used in the first place. The magenta dye is thus too red, while the cyan dye also has some magenta bleed, making it too blue.

These faults also existed in the print's cyan and magenta dyes, and those faults were often over-corrected in the negative - especially in film destined for amateur consumer use. This is why our more perfect RGB image is often oversaturated, because it doesn't use faulty dyestuffs!

So there's usually no problem accommodating colour negative dyes in a modest RGB colour space. It's only when the steep tone curve needed is applied that over saturation becomes an issue.

Film produce huge amount of saturation, so it require really large digital color space to work normally.

Yes, it has such a potential (what's the gamut of the scene, the film used etc?). And a color target who's gamut is sufficiently large enough a container to define an input profile to get to a large RGB Working Space gamut.

Evidence for that?

The ProPhoto RGB color space, also known as ROMM RGB (Reference Output Medium Metric), is an output referred RGB color space developed by Kodak. It offers an especially large gamut designed for use with photographic output in mind. The ProPhoto RGB color space encompasses over 90% of possible surface colors in the CIE L*a*b* color space, and 100% of likely occurring real-world surface colors documented by Pointer in 1980,[3][4] making ProPhoto even larger than the Wide-gamut RGB color space. The ProPhoto RGB primaries were also chosen in order to minimize hue rotations associated with non-linear tone scale operations. One of the downsides to this color space is that approximately 13% of the representable colors are imaginary colors that do not exist and are not visible colors.

ProPhoto RGB color space - Wikipedia

So there's usually no problem accommodating colour negative dyes in a modest RGB colour space.

Usually or never? You understand, there's no reason to guess and no harm using a container for a color space that is KNOWN to be large enough. Hence, ProPhoto RGB.

Some apps just use ProphotoRGB primaries and different gamma.

If you guys want to enter into a technical discussion, let's get the technical stuff correctly defined, OK?

Sorry, if the TRC isn't 1.8, it's not ProPhoto RGB. A Working Space has primaries, white point and TRC/Gamma that define them exactly. IF the gamma isn't 1.8, it isn't ProPhoto RGB. You can build a Working Space with ProPhoto RGB primaries and a different TRC or Gamma than 1.8 and call it "Dmitry RGB" if you wish but it's not ProPhoto RGB.

For example Lightroom/ACR for processing transform internally debayered data to ProphotoRGB primaries with linear gamma transformed in the end to sRGB gamma i guess (formally they name this Melissa RGB).

No. Melissa RGB is the color space used in Lightroom for the Histogram (NOT processing) that uses ProPhoto RGB primaries and a 2.2 TRC like sRGB. It's called Melissa RGB BECAUSE the TRC isn't a 1.8 gamma. Or that would define ProPhoto RGB. Melissa RGB isn't used anywhere expect in the Histogram in Develop module without a soft proof. The underlying color space used for processing (again, ProPhoto RGB primaries and WP but 1.0 TRC) has no name.

All explained decades ago:

http://digitaldog.net/files/18Color Management in Lightroom.pdf

ProPhoto RGB does not have a "tiny linear slop"; its got a 1.8 gamma (which differs slightly from a TRC).

Then somebody needs to tell the writer of the Wikipedia ProphotoRGB page.

Screen shot from Wikipedia.

ONE space created by Kodak (is actually named ProPhoto RGB***) has a TRC of 1.8. They also specified a similar space, the only difference being the TRC: it's called ROMM RGB/ISO 22028-2:2013. Look it up.

Sorry, RIMM (got that "i" wrong):

https://www.color.org/chardata/rgb/rimmrgb.xalter

Nope, you simply haven't learned how to render output referred** data from there!

http://www.color.org/scene-referred.xalter

** http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf

This is really useful info.

By the way, i just compared those "flat" exported files processed in Lightroom/ACR with Process Version 2003 or 2010 and with all adjustments turned off, and they still look not the same "flat" as real "flat" untouched exports from other raw editors.

So probably that scene-referred image export may be the only technically correct way to go for Lightroom/ACR film scan exports.

Overall i don't use Lightroom/ACR, so i may not understand it as pure as i understand other tools.