Colormanaging scanned negatives - How to do best ?

[Mark D Segal]

ColorNeg/ColorPerfect is a PS plugin that may help.  I tried a demo version a while ago for scanning negatives as positives, then removing the orange mask and inverting.  I didn't work with it much and didn't get good results immediately.  Maybe with a little more learning I could have achieved better results.  http://www.c-f-systems.com/Plug-ins.html#plugdesc

Has to be some of the most dense, convoluted and unreadable material on the internet. Why should people subject themselves to this punishment when there are simple and effective alternatives?

[Mark D Segal]

regarding my post.. yes i know there are def. different orange masks (i developed some GDR orwo color negs myself).. and again.. i wont try this method as i totally agree with you that silverfast negfix is prob. all we need.. but im still pretty sure this process will work!

if i want to scan an orwo film.. of course i have to use orwo for the profile!..

but another aspect you guys talk about is the prophoto "thing" with negafix.. actually i have the feeling the whole colormanagement in silverfast doesnt work for negatives!!

i get different colors weather i use adobe s or prophoto.. although i dont assign it but use it in silverfast ist working space!.. thats a bug right?

it should always keep the konstant colors and use the scanners profile or gamut as ICC and then convert to my workin space and not asign..

thats typical to get redish reds.. if you just assign prophoto!

I wonder how many people in the world use ORWO film these days? No matter, it isn't mainstream stuff that industry is rushing out to cater for. As a negative film, and as we've been explaining in this thread, there is no ICC profiling for it. You need to use another approach for neutralizing the orange mask, decompressing the contrast and inverting the colours. NegaFix in SilverFast would be a decent start, because you have a choice of about 127 different profiles from which to build on. Given what ORWO film was, you would probably have the best chances within the Agfa group. But most likely you will need to create a custom Negafix profile by using the Expert Dialog controls in the Ai Studio version of SilverFast.

Colour management does work with negatives in SilverFast - any such colour control operations require at least a colour working space. The observation of reddishness emerging from the combination of NegaFix and ProPhoto doesn't nullify the whole functionality of colour management in SilverFast when handling negatives.

I've never heard of "adobe s" so I can't comment on that.

As we've been trying to explain here, there is no scanner profile for handling colour negatives. And reds should be reddish. It's the other colours that shouldn't be reddish.

I'm not at all convinced that this observed reddishness has anything to do with whether colours are rendered from an assigned profile versus converting the colours to Pro Photo. That remains to be determined.

[Mark D Segal]

This may be true, but I think I'm not even getting to that point.  From this discussion I'm getting that somehow the orange cast be compensated for and then the colors inverted, you all are relying on the Silverfast scanning software to do these steps.  I guess my question is can this be done without silverfast.  What if you had a simple scanner and software and ended up with just a scan of your negative just as it is, negative and orange, in a tiff (or whatever, in my case it would be a NEF).  Is there any way to get from that to a half decent positive image?

Yes there is. I have explained all this step-by-step in extensive detail in the tutorial I created for this website and is hyperlinked above in this thread. It all works, but SilverFast's NegaFix is just so much easier and produces very good results when used properly.

[dmerger]

Has to be some of the most dense, convoluted and unreadable material on the internet. Why should people subject themselves to this punishment when there are simple and effective alternatives?

Reminds me of what a lot of people say about Silverfast.   

Yes, the web site is pretty dense, but actually using ColorNeg/ColorPerfect isn't any more difficult than using Silverfast.  It's probably a little easier.  As far as I remember, ColorNeg/ColorPerfect uses negative film profiles in a manner similar to Silverfast.

[MonsterBaby]

@mark..

 i just used orwo as an example of a very different mask. thats all ;-) and like i said.. i am not going to try that either as negfix does it for me.! even with orwo. .;-) it was just a theoratically aproach.

"i get different colors weather i use adobe s or prophoto" .. sorry.. if i was a little fast here.. i am sure you have heard about it:

i get different colors weather i use AdobeRGB or sRGB or proPHOTO 

and this cannot be right!.. there cannot be a colorshift when i use different WORKING spaces.. there can be clipping of course but not shifting.

its very obvious that negfix "produces" f.e. a red that is 255/0/0.. and then just assigns the workspace to it.. by "accident" Adobe RGB seems to fit best..

[Christoph C. Feldhaim]

I just had a call to Lasersoft and the guy I was talking to admitted that there is a problem and they are working on fixing it.

He basically said that in the moment it seems so, that the numbers of the file are being kept in AdobeRGB and Prophoto (or sRGB) is just assigned and that the conversion seems not to happen.
This sounds like AdobeRGB would be always the internal colorspace, no matter what you do.
But they are still examining it and he promised to send me a beta version with the fix if they find the bug.

I am not sure what happens when not using an internal colorspace at all in SF8 - if the numbers of the file represent the scanners native RGB (in my case "SF_T(Nikon LS9000)") or AdobeRGB.
I'll check against a target visually as soon as possible to see whats the best solution.

[MonsterBaby]

"He basically said that in the moment it seems so, that the numbers of the file are being kept in AdobeRGB and Prophoto (or sRGB) is just assigned and that the conversion seems not to happen. "

isnt that what i said ? well as long as no one else noticed it.. ;-)   

the bug is only with the negs tho.. CM works nicely with slides

[Mark D Segal]

Reminds me of what a lot of people say about Silverfast.   

Yes, the web site is pretty dense, but actually using ColorNeg/ColorPerfect isn't any more difficult than using Silverfast.  It's probably a little easier.  As far as I remember, ColorNeg/ColorPerfect uses negative film profiles in a manner similar to Silverfast.

Dean, if you haven't peaked over there for a long time go over to SilverFast.com and download a demo of SilverFast 8. They got the message and you'll be pleasantly surprised.

[Mark D Segal]

I just had a call to Lasersoft and the guy I was talking to admitted that there is a problem and they are working on fixing it.

He basically said that in the moment it seems so, that the numbers of the file are being kept in AdobeRGB and Prophoto (or sRGB) is just assigned and that the conversion seems not to happen.
This sounds like AdobeRGB would be always the internal colorspace, no matter what you do.
But they are still examining it and he promised to send me a beta version with the fix if they find the bug.

I am not sure what happens when not using an internal colorspace at all in SF8 - if the numbers of the file represent the scanners native RGB (in my case "SF_T(Nikon LS9000)") or AdobeRGB.
I'll check against a target visually as soon as possible to see whats the best solution.

First, this is excellent news - better late than never.

As to what's been happening, I doubt this is an issue related to whether profiles are assigned or there is a conversion. My hunch is that it's a mapping issue.

If you scan a negative (at least in one of these Nikon scanners - in my case SC5000ED) with no profiling whatsoever and open it in Photoshop, you get the missing profile notice. If you assign ProPhoto you will get the influence of excessive reds. If you assign ARGB(98) it will look fine. If you assign ARGB(98) and convert to the working space (ProPhoto) in Photoshop it's also fine. The problem only occurs when you travel straight from the scan to ProPhoto in Photoshop, or chose ProPhoto as the internal space in SilverFast. If no working space is assigned to the scan, my understanding is that the unmanaged data is sent from the scanner unmanaged and stays that way until you make a decision about how to manage it. Anyhow, let us hope that this will soon be academic.

[Christoph C. Feldhaim]

The simple fix in the moment is:

Any positive file created from a neative scan using Negafix requires AdobeRGB as first assigned colorspace. Be it in Silverfast or in PS later.
This is mandatory for now until they have fixed it.
Assigning my scanner colorspace just worked because it doesn't differ too much from AdobeRGB.

[Mark D Segal]

The simple fix in the moment is:

Any positive file created from a neative scan using Negafix requires AdobeRGB as first assigned colorspace. Be it in Silverfast or in PS later.
This is mandatory for now until they have fixed it.
Assigning my scanner colorspace just worked because it doesn't differ too much from AdobeRGB.

Correct, and in fact if you are making prints, the bottom line is the relationship between the gamut shape and volume of your printer profile versus that of the scan, and the bottom line below that bottom line is the kind of image it is and what differences our eyes can see!

[dmerger]

Christoph, your experience with Silverfast and mine are similar.  Using aRGB solves the profile mismatch problem.  Of course, as you already mentioned, using aRGB means that you may not get all the colors your scanner can produce. 

A while ago, I did a few general scanning tests.  I was just trying to determine which scanning software produced better negative scans with my scanner.  My tests were not intended to compare gamut. I randomly selected three photos.  To my surprise, one of them showed gamut clipping with Silverfast and aRGB compared to my scanner’s native color space. Converting from my scanner’s native color space to PhoPhoto didn’t show any clipping.

BTW, the photo wasn’t one where I would have expected a gamut larger than aRGB.  It wasn’t a colorful sunset or saturated flowers.  However, I didn’t print the photo, so I don’t know if the gamut differences would have been noticeable in a print, but I suspect not. In any event, I know you’re fully aware of gamut issues.  Just thought you’d be interested in my experience.

[Christoph C. Feldhaim]

After all we can overcome these gamut issues by using the method Mark described in his tutorial.
Using an HDR scan with the real raw data from the scanner and the orange mask subtraction trick no colors should be lost.
I'll do some further testing tonight...

[Christoph C. Feldhaim]

After some testing today I found out the following:

1. You can apply a Gamma value to the HDR scans of Silverfast 8  in the preferences by activating the "for HDR output" checkbox right of the Gamma setting

2. If you deactivate it you get a Gamma of 1 (linear) which seems to be the true raw data. Leaving it activated and setting Gamma to 1 has the same effect.

3. Now the interesting thing:
If you scan with a Gamma of 1 and try Marks method of reversal using the orange mask in photoshop there still is a strong color cast. Marks method doesn't work anymore (He recommends Gamma 2.2)

4. BUT:
If you do this with a Gamma set to 5.0 (the maximum possible) the scan is much lighter, but the reversal process using the orange mask produces a far better removal of the color cast than using a Gamma of 1 or a Gamma of 2.2 as recommended in Marks article.


I am still doing some more testing, since I am not completely sure yet, what this Gamma acrobatics does to the histogram, but in the moment it looks not (yet) too bad.

EDIT:
Attached jpegs derived from the PSDs made from the scans. See filename for Gamma info.
Tonality was restored after the inversion by orange mask subtraction with a simple levels adjustment.

[Christoph C. Feldhaim]

Here are the PSDs shrunk to 25%

[Mark D Segal]

The Gamma Acrobatics, as you put it, affects mid-tone brightness and contrast. It is similar to adjusting the middle slider of the Input Histogram in Levels in Photoshop. You are correct that a Gamma value of 1.0 is the "more raw" data insofar as it is linear. The problem with it is that it's almost always much to dark to be useful. That is why they provided that check-box "for HDR output" - to help make sure you get user-friendly brightness and contrast in external applications.

I never experimented with Gamma 5.0 simply because I figured it would be far too bright to be useful, but just as well you are thinking out of the box and coming up with some interesting outcomes. It surprises me however that 2.2 results in the kind of cast your image shows. I didn't get that in mine, which would have shown through the memory colours in the test image I was using. What this means is that brightness is affecting hue in the reversal process. Worth further investigation!

[Christoph C. Feldhaim]

Yes - for me it was totally unexpected as well.

[Christoph C. Feldhaim]

After some thinking it appears totally clear to me why happened what happened what I described above with the various Gamma settings.

Actually the idea of just subtracting the orange mask to get good color is naive.
The idea of just subtracting the orange masks is based on the assumption, that the gradation curve is linear and has a slope of 1 and that all three color curves are strictly parallel.
This is obviously not the case.
Neither the 3 curves are linear, nor do they have a slope of 1 nor are they parallel.
Using the "right" Gamma value can partially, but not completely correct this error and
this is more or less a random result.
A correct neutral grey point (and whitepoint) must be defined additionally the blackpoint (orange mask).
The nonlinearity of the films gradation curve is where the characteristics of the film lie (pun intended),
and all three curves (for each basic color) are different and have different symmetry properties and slopes, but
the big color shift we can see in the images above comes from the wrong whitepoint and increasing the Gamma just changed this.

So - the proper method would be:

1. Orange mask subtraction like described
2. Definition of the correct whitepoint (or neutral grey in the almost linear middle of the curve) to get rid of the colorcast.
3. Levels adjustment (Luminosity)

Setting the correct greypoint or whitepoint in this linear transformation will make it possible to work with any gamma value.

The amount of the mistake depends on the film curve characteristics and
since the curve is modified by the applied Gamma, Gamma has an influence on the mistake.

I hope that could clear up things a bit.

Orange mask subtraction just does an offset correction, but not the necessary slope correction of the curves.

Cheers
~Chris

[Mark D Segal]

Hi Chris,

I think what you are saying boils down to the following propositions.  Starting with colour cast - the colour of the mask is uniform so once it is neutralized it should be neutralized for the entire image, and if there remains a colour cast after neutralizing the hue of the mask it should not be on account of the mask. Colour casts not related to the mask should be neutralized by correct setting of the black and white points in the "de-masked" image (the minimum necessary intervention for doing this can vary; sometimes one needs to correct black point, white point and middle gray; sometimes one or two of them work fine). Turning to luminosity, The scan of the image is linear unless Gamma > 1.0 is applied in the scan software, but of course the film curves are as you say totally non-linear - by design. So we are always making linear scans (if we set gamma at 1.0) of non-linear media, and needs adjustment in Levels or Curves. So I think we end-up in the same place: get rid of the orange mask bias, correct remaining cast and deal with luminosity. All that still doesn't get to the bottom of why you got better results from Gamma 5.0 than 2.2 or so. That one I need to mess around with both in my mind and with the tools, as soon as time permits!

[Christoph C. Feldhaim]

Gamma compresses on one side of the curve and expands on the other side of the curve if it is not equal 1, since its an exponential function.

f(x)=xgamma

for gamma = 1 there is f(x)=x

x values are normalized between 0 and 1.

This sort of shift moves the curve in a way which probably comes near to the required setting of white  point (black point we have set with orange mask removal).
It appears applying a high gamma as I did comes close to what happens if the white point has been set properly.
I'll do some drawing curves and stuff tonight to understand it better, but as a first step in understanding this it appears to me just so. In the moment I see it as a mathematical problem which has to do with the nature of the gamma function and how it transforms the curves.