How to manually process film negative from linear tif file?

Currently I use Photoshop and ColorPerfect to process color film negatives. Scan is produced with DSLR and RAW file processed through MakeTiff utility from ColorPerfect to create linear TIF file which is then run through ColorPerfect in Photoshop. I'm curious to know what would be the workflow to manually process the linear tif file in photoshop without Color Perfect. I can process non-linear negative pretty easily manually in photoshop by manually removing orange mask, inverting the image and adjusting rgb levels and curves to set black point, white point and color balance. How would I process an image that doesn't have gamma assigned and reap whatever real or hypothetical benefits that provides. I don't fully understand the benefits of ColorPerfect working with linear files vs non-linear, but I presume there should be a benefit. Thank you.

"Non-linear" might refer to logarithmic interpretation of color channel exposure, or compressed v non-compressed TIFF files. You need to know what ColorPerfect means.

 

Manual rendering of negative film requires compensation for the orange mask, optimizing the remaining color channels, and adjusting the results. The color balance is strongly affected by the light at the time of exposure, and the exposure level of the film. Not all color channels are equally sensitive. I use the back end of Silverfast HD scanning software to process negatives, with reasonably good results if I mask to exclude the borders. I hear that ColorPerfect automates this process even further.

 

I would not recommend strictly manual conversion if you have other things to do with your free time.

Linear is simply the TRC (or gamma) of the encoding and hence, 1.0. Nothing at all special about this. There's simply a linear tone curve (kind of like the 'default' curves dialog that is shown).

You DO need a profile to define this color space and TRC/Gamma or the image will appear 'dark' because the assumed profile isn't linear.

See: http://digitaldog.net/files/LinearityandGamma.pdf

Every characteristic curve I've seen for film or digital has been exponential on the abscissa (exposure) and logarithmic on the ordinate (density) axes. That's largely because human eyes and ears respond logarithmically.

What characteristic curve for digital?

Raw data is linear.

Rendered images may be, usually not. sRGB has a 2.2 TRC. Adobe RGB has a 2.2 Gamma, ProPhoto RGB has a Gamma of 1.8. Etc.

From a Maketiff raw file:

A negative image would need inverting first, or the inverse of the above curve applied.

 

Personally, I've found no need to go through Maketiff to process digitised colour negatives. Since you'll only need to apply a curve similar to the above to each and every 'scan'.

The inverse of linear ”curve” is linear. The inverse of a none linear isn't. But again, raw data itself is linear encoded. How it is rendered as seen above, with some curve applied is a different story.

A true Linear TIFF has no such curve. That's what makes in linear.

Any image can be inverted (made negative) using the curves tool.

 

The original of the above image inverted, and the mirrored curve applied.

sRGB has a 2.2 TRC. Adobe RGB has a 2.2 Gamma, ProPhoto RGB has a Gamma of 1.8. Etc.

It might help the OP to explain that the gammas of 2.2, 1.8, etc. are needed to correct the non-linear response curve of monitors

It might help the OP to explain that the gammas of 2.2, 1.8, etc. are needed to correct the non-linear response curve of monitors

Not so at all!

One can easily view a 1.0 gamma encoded image properly when an embedded ICC profile defines this color space along with the display profile that defines it's behavior which can be any TRC. Then an ICC aware application along with a display profile WILL produce a correct preview. ICC color management divorces the display and the image data by design and that's why there are profiles for the display and profiles for the image, both used to conduct a color managed preview (Display Using Monitor Compensation). The OP doesn't need to be concerned with any defined TRC or Gamma, simply be concerned with profiles for image data and display and use color managed software.

 

You simply need to study basic color management to see this fact and I'd be happy to supply both a 1.0 linear TIFF from an older Kodak DCS camera that could produce it, and in ICC profile that defines this capture. It previews exactly as it should, with color management using the correct profiles in play.

IF you view a linear TIFF without it's profile defining that it is indeed linear, it will appear too dark, due to improper color management at play.

IF anyone wants a link to such a TIFF and ICC profile, just ask: Proof of concept is key, not assumptions on how images are displayed with proper color management.

One can easily view a 1.0 gamma encoded image properly when an embedded ICC profile defines this color space along with the display profile that defines it's behavior which can be any TRC.

But surely that only gives a one-off view that's tied to the profiled hardware? It makes no change to the file.

 

I think the OP is looking for a more portable solution. One that transforms the Maketiff linear image into a form that can be viewed more universally. Such as sRGB or AdobeRGB.

 

Since they both use a nominal gamma of 2.2, wouldn't that be a sensible choice of curve to apply?

 

The curves tool in PS or any other decent image editor, shows the input and output values (though only 255 levels, even in 16 bit mode) for any point on the curve. Therefore it can be used to form a template for a gamma transform.

 

Only a few points on the curve need be input, since the Bezier function will automatically smooth out the curve.

 

This table should be enough points:

Input 10, output 59

Input 50, output 122

Input 127, output 186

Input 204, output 230

 

The curve can be saved as a preset once created.

 

Yes, I know that sRGB has an inexplicable linear section in the deep shadow region, but visually this is almost indistinguishable from a pure 2.2 gamma.

But surely that only gives a one-off view that's tied to the profiled hardware?

 

Not so. It should be portable to any system using ICC color management.

 

The embedded profile establishes the meaning of the image pixel values vs the so-called "profile connection space." So an ICC color management system "knows" what the colors should look like and should therefore properly translate them to any profiled output device, such as a monitor.

 

To be clear, I'm not saying that I think this is a good idea; I'm just saying that it should function properly within any color-managed system. It is NOT limited to specific hardware in a "one-off" manner.

Bills got it. Other than the OP, you're all just making this more complicated by mostly misunderstanding of a simple process.

 

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

Not so at all!

Color management 101 tells us that gamma correction initially was needed to correct the very non-linear behavior of CRT monitors and Apple printers. That it has gotten more complicated over time doesn't take away that fact. Talk about making easy things difficult!

Color management 101 tells us that gamma correction initially was needed to correct the very non-linear behavior of CRT monitors and Apple printers.

No, it doesn't. No matter how much you repeat it. You actually need to find a book on color management 101 before posting again.

Profiles don't correct, they define device behavior hence their names. That you think they correct, of all attributes, non-linearity show again, this is a subject you don't really understand. Kind of like the CCT of Solux bulbs; remember that set of misunderstandings from way back? :)

Clearly the idea of downloading documents I've provided, to learn how this works isn't in your playbook. The offer stands for others who actually want to see proof of concept before posting here on this topic.

Profiles don't correct, they define device behavior hence their names.

Reading 101, if applied, would show you that is not what I said. I was talking about gamma correction. Profiles are part of what I referred to as the issue getting more complicated over time. Please start thinking critically before shooting off.

Reading 101, if applied, would show you that is not what I said. I was talking about gamma correction. Profiles are part of what I referred to as the issue getting more complicated over time. Please start thinking critically before shooting off.

What you wrote was OT and wrong. Displays can have a linear or non linear behavior without issue WITH color management properly implemented. That fact has been lost on your again. But I'm not trying to convince you of any colorimetric facts or facts otherwise, we've got too long a history in that area. One where you are so often dismissed.

I'm replying so others here can decide who's got expertise and experience discussing this topic and who hasn't. They can decide from there. I believe most readers have more critical thinking than you give anyone credit for, they can decide for themselves who to listen to.

 

I can calibrate my SpectraView to a linear behavior IF I wish. So can you, if you try and examine the facts before posting again assuming you found a SpectraView who's flicker didn't give you headaches.

Unlikely and in fact you most certainly will.

 

http://digitaldog.net/files/DisplayGamma1.jpg

What you wrote was OT and wrong. Displays can have a linear or non linear behavior without issue WITH color management properly implemented. That fact has been lost on your again. But I'm not trying to convince you of any colorimetric facts or facts otherwise, we've got too long a history in that area. One where you are so often dismissed.

I'm replying so others here can decide who's got expertise and experience discussing this topic and who hasn't. They can decide from there. I believe most readers have more critical thinking than you give anyone credit for, they can decide for themselves who to listen to.

 

I can calibrate my SpectraView to a linear behavior IF I wish. So can you, if you try and examine the facts before posting again assuming you found a SpectraView who's flicker didn't give you headaches.

Unlikely and in fact you most certainly will.

Spoken like a true Saul Alinsky apparatchik: obfuscate, attack, destroy, the hell with them all.

Spoken like a true Saul Alinsky apparatchik: obfuscate, attack, destroy, the hell with them all.

For the mod's sake, this is the last time I'll reply here as you must get in the last, incorrect, OT word in most forums and this thread is not an exception.

 

One of us wrote a self published book of political fiction and apparently cannot produce a photograph (no proof of concept he can or has)

I promose never to argue with you about Birtherism as I don’t believe it any more than the Earth is flat, windmills cause cancer or the 2020 election was stolen by massive voter fraud.

 

The other person here has a well known publisher of technical books publish tens of thousands of copies of his books on color management (the subject), and has published many dozens of magazine articles on color management, is a member of the ICC, has lectured and taught the subject around the world and has actually made some images (and can show them in the galleries of this site), and in the past, was paid to do so by some Fortune 100 companies.

 

And thus, those reading what each of has to offer on this subject can decide who to listen to. Adiós Frans.

Edited December 15, 2020 by digitaldog

The application of an embedded profile requiring such steep tone-curve correction would mean using the original 16bit/channel TIFF as the portable file. That's if severe posterisation is to be avoided.

 

That's not very efficient or convenient; when the curve could be simply and permanently applied. The file could then be exported as an 8 bit version for general display.

The application of an embedded profile requiring such steep tone-curve correction would mean using the original 16bit/channel TIFF as the portable file. That's if severe posterisation is to be avoided.

What's posterization got to do with anything discussed? Why would anyone edit an image in any way without doing so in high bit (if they have such data and they should from a scanner) if they care about potential data loss? And what's that got to do with profiles?

Also worth pointing out; few originals are true 16-bit encoding. Even Photoshop doesn't work with 16-bit under the hood (it's 15+1 bits) and it and most other products, treat all high bit data (10-12-14 or maybe 16-bits) as the same in terms of the processing.

The file could then be exported as an 8 bit version for general display.

I don't know what you mean by 'general display' but 8-bit per color data or high bit data is displayed the same way. NOT all display paths are high bit. Not all panels are, not all video subsystems, not all applications or even OSs (depending on age) provide a full high bit display path. All must support high bit for a high bit display path.

Which is why so called "posterization" can be in the video path and not within the image data whatsoever. One can see it, it doesn't exist in the actual image data.

But again, I have no idea what any of that has to do with the OP's question about image encoding; TRC or gamma.

What's posterization got to do with anything

Yep, attack, discredit, destroy, marginalize, etc. etc. Apparatchik behavior straight out of Saul Alinsky's playbook.

Yep, the more drastic adjustments are made, the greater the chances for visible posterization.

Why would anyone edit an image in any way without doing so in high bit (if they have such data and they should from a scanner) if they care about potential data loss?.

http://digitaldog.net/files/TheHighBitdepthDebate.pdf

If you look at the histograms from a digitised colour neg, you'll see that they occupy only a fraction of the possible brightness range. They need all the help they can get in terms of bit-depth. But none of this makes any difference to the fact that high bit-depth files are inefficient for both storage and transmission. And doesn't help the OP in the slightest.

 

Anyhow. I went through the steps needed to get from a Maketiff file (from RAW) to a passable positive image. It's not something I'd care to do on a regular basis.

 

This is the Maketiff from a Sony camera digitisation of a colour neg.

 

First we need to align and expand the RGB histograms using levels manually - Auto Levels just didn't work.

This gets rid of any remnant orange mask as well as the excess Bayer green.

 

BTW, you may need to do this critical levels adjustment in two stages. Since the initial individual RGB histograms are too narrow to accurately place their end-points by eye.

 

Next we need to invert and apply a suitable curve. I did this in one go, using this inverted curve.

Which got me this:

The colours off, but at least it's in the right ball park.

A grey-point pick got me this:

Closer, but the colours are muted. So a touch of saturation enhancement was applied:

That's more like what was actually in front of the camera.

Still not perfect, but I was losing the will to live by this time!

 

All above steps were done in 16 bit/channel mode, then downsized and converted to JPEG for posting here.

 

I can only repeat. Starting with a linear Maketiff/RAW image and manually adjusting it isn't a workflow I'd recommend!

Edited December 16, 2020 by rodeo_joe|1