Generating a Kodachrome profile from an IT8 target

[dmerger]

Guy, I looked at your IT8 Adobe RGB scan, using both the original Adobe RGB profile and the XYZ profile you made. Indeed, there is a significant difference between the two profiles, but neither appears to produce a good result.  Both profiles produce major color casts.  My initial reaction is that it would be difficult to say which profile is actually better.

I compared your scan to my linear scan of my Velvia IT8 target with the generic Minolta linear profile. My scan appears to be much, much better than your result.  They aren't even in the same ballpark. The comparison that really matters, however, is how close your IT8 scan matches your IT8 slide.

Of course, you're scanning Kodachrome and I'm using Velvia, which may account for some of the difference.  In any event, I thought that you might be interested in the comparison. 

[guyburns]

Thanks, Dean, for having another look at my profiles. I have several Velvia targets, and generated profiles from them at the same time as I did the Kodachrome profiles, but haven't tested them yet. The targets themselves are different. Two examples: the vertical cyan column starts with virtually white for the Kodachrome (obvious pale blue for Velvia), and ends up slightly less saturated-looking than the Velvia cyan. And the bottom-left 4x4 set of patches are obviously more saturated for the Velvia than the Kodachrome.

I have uploaded a comparison of the two, called Kodachrome & Velvia IT8 Comparison, to http://www.mediafire.com/?thogddgfozxi2. The particular Velvia is Velvia RVP50. Even though there are differences, that might not explain why my scans and profiles are different. Maybe my scanner, or the profiles, are not as good as they could be.

I'd like to see your scan of the Velvia target and compare them with mine. Could you send me, or upload, an image of the target with embedded profile? You can gmail me at gdburns.

A Question
I've been trying to install profiles onto the PC I've been given. I've tried right-clicking then selecting Install, but Windows comes back with an error message "This is not a valid profile". So I manually put them in this folder: \Windows\system32\spool\drivers\color, and then they can be applied. Any idea why right-click > Install won't work?

Bug in NikonScan?
Finally, when I turn CM on and select Scanner RGB in NikonScan, there is no profile applied when I open the image in Photoshop, both on the Mac and PC. Must be a bug in NikonScan. For all other colour-managed spaces, the image arrives in PS with the appropriate profile embedded.

Edit: I didn't read Nikon's Color Management PDF carefully enough. On page 89 it says of Scanner RGB:

This profile replicates the color space achieved when scanning with Nikon CMS off… In order to produce the effect achieved by turning Nikon CMS off, the monitor profile is not used, nor is an ICC profile included with the image when it is opened in the host application.

So Scanner RGB does not include a profile. But the statement implies that Scanner RGB should give the same colour numbers as when CM is turned off, but that's not what I found. I'll have to rescan using both settings and double check if the scanned image is the same.

[dmerger]

Bug in NikonScan?
Finally, when I turn CM on and select Scanner RGB in NikonScan, there is no profile applied when I open the image in Photoshop, both on the Mac and PC. Must be a bug in NikonScan. For all other colour-managed spaces, the image arrives in PS with the appropriate profile embedded.

Here is what I wrote above about this problem.  "I've read that when you ... select Scanner RGB in CM, that the scan opens in PS with sRGB imbedded, which is a defect in the software.    ...

 See: http://www.nikonusa.com/pdf/manuals/Scan4/NikonScan-4_CMS_en.pdf"

Also note what I wrote above asking if you had a profile for Scanner RGB.

It appears that either there is no profile attached or an incorrect profile.  So, if you want to use CM on and Scanner RGB, and not use a profile you make, you should try to find a Scanner RGB profile in the Nikon Scan program files.

[dmerger]

A Question
I've been trying to install profiles onto the PC I've been given. I've tried right-clicking then selecting Install, but Windows comes back with an error message "This is not a valid profile". So I manually put them in this folder: \Windows\system32\spool\drivers\color, and then they can be applied. Any idea why right-click > Install won't work?

No idea.  I downloaded your XYZ profile from your Adobe RGB  IT8 scan, and that profile installed on my PC (Vista 64 bit) by right clicking and clicking on "install". 

[dmerger]

My Velvia 50 IT-8 slide is also different from your Kodachrome IT-8 slide.  So, in my comparison I focused on the grey scales.  

I expect that few if any of the grey scale patches are perfectly grey, with each of the RGB values being equal, but I assume that they should be close. All those patches on my scan have RGB values that are close to the same.  In other words, my grey patches are close to being perfectly grey. Your grey patches, except in the some mid-tones, are far from grey.  

Here are a couple of examples of the RGB numbers from my scan versus your scan with your XYZ profile:  

Patch 5:  Mine: 181 181 183.  Yours: 176 191 172

Patch 20:  Mine: 32 31 32.  Yours: 24 20 12

Here is my IT-8 scan.  I scanned it as 16 bit linear, opened it in PS and assigned the generic Minolta linear profile, converted it to aRGB, changed it to 8 bit, reduced the size and saved as a jpeg. (Note, I think that I may have slightly over exposed the scan, but I don't thing that slight over exposure is significant for the comparison.)

[guyburns]

My Velvia 50 IT-8 slide is also different from your Kodachrome IT-8 slide.  So, in my comparison I focused on the grey scales.  

I expect that few if any of the grey scale patches are perfectly grey, with each of the RGB values being equal, but I assume that they should be close.  

[Note: Excuse the lengthy posts. I use the information in threads I start as my archive of pertinent info. I lose things too easily on my computer, and this way, other people can comment if something I have said is amiss.]

I don't think the grey patches are truly grey. I looked up the Kodachrome and Velvia text files that contain the colour info for the IT8 targets. These are the numbers for Patch 5, taken from the GS5 (Grey Scale 5) row in the text files:

Kodachrome GS5: 69.79, -8.84, 3.65
Velvia GS5: 65.89, -1.54, 2.07

When I typed those numbers into PS to see the colour, there is an obvious difference – the Velvia is almost grey whereas the Kodachrome has a distinct green tinge. In the IT8 world, it looks like greys are NOT grey, and they differ from target to target.

GS5 COLOUR NUMBERS
The figures you quoted for GS5 colour numbers for my Kodachrome scan and your Velvia scan may not be truly representative of the actual colour numbers of Patch 5. Two reasons:

1. There is quite a bit of variation within each patch. If you move around inside a patch, the colour number change significantly. This is best seen by looking at the histogram of a patch which will show a spread of values.

2. If you downsample the image (the Velvia jpeg was 1000 pixels wide, the Kodachrome was 2700 pixels wide), the variation becomes smaller because the pixels are averaged.

I brought up this point with Andrew, the author of Coca, about a month ago. This is what I asked:

I'm slowly working my way through testing Coca. In one of your emails you quoted from the Argyll site: "The TIFF file can be either 8 or 16 bits per color component, with 16 bit files being slower to process, but yielding more accurate results". I don't understand how that can be the case. When I look at any of the colour patches in Photoshop, there is a wide range of values within each patch. Why would 16-bit resolution give any better results than 8-bit, given the wide range of RGB values for what should be a single value? Maybe I have missed something, but if the average was taken of these numbers (chosen at random, but assume they are supposed to be a single value of 1.23 sampled at 16-bit):

1.23456
1.20897
1.25639

You get an average of 1.2333. If you find the average of the numbers rounded to 2-decimals (1.23, 1.21, 1.26) you will get a result that is no less accurate because the original readings varied so widely.

I received this response: "Indeed, you make sense. I don't know the answer, so I send your question to Graeme, the guy who created Argyll. Let's see what he is going to say." A few days later, Graeme replied through Andrew:

Well, if noise in your system sufficiently dithers the quantization, then no, 16 bit is not likely to make much difference. But this is not necessarily the case with all systems or device values. Some device values on some systems can show systematic biases to 8 bit quantized values (e.g. significant numbers of pixels of values 3, 4 and small numbers of other values). The other thing to keep in mind is that scanin can (and is sometimes) used on synthetic images rather than real world images, where there is no source of natural noise to dither 8 bit quantization. The other aspect is simply - why throw information away unnecessarily, and subject the system to the uncertainly of whether 8 bit quantization will play a role in the end result ? Offering the option of 16 bit processing allows a resolution of this uncertainty. Graeme Gill.

What I take from all the above, given the spread of colour numbers in each patch, is that "16 bit is not likely to make much difference", but you may as well use it because: "why throw information away unnecessarily".

It's seems to me that colour profiling has quite an amount of room for error. For example, in the Velvia GS5 patch in the scan previously uploaded – already averaged by resampling and jpeging – the RGB values ranged from:

R: 179-185
G: 179-187
B: 179-186

Quite a spread – but the Kodachrome spread was even wider.

GRAIN & DUST
And this leads me to another point: what should be done about dust spots and blemishes on the scan? I assume the profiling software averages each patch. If so, unless it clones out the dust, or ignores any values that are obviously in error, then it will be averaging dust, hairs, grain, blotches and actual patch colour. I have always turned on Digital ICE to remove most of the blemishes, but a few still remain so I get rid of them. However, Hutchcolor reckons otherwise (and I reckon the author is wrong: how can a simple average improve the situation when noise is present?):

Q: Upon enlarging the HCT target scan I notice a lot of grain in the patches. Should I attempt to smooth out the grain before creating the profile?

A: NO! Any grain you see is a normal product of film emulsions and/or the scanner, and is actually valuable in helping an 8-bit per channel scanner "see" more that the normal 256 tone levels. Good profiling software will integrate (average) the grainy pixels to produce an RGB value with better than 8 bit precision. If you try to smooth the HCT target scan (or even a live original) for example with a noise filter, you will actually be reducing the precision of the profile.

Maybe there is some validity to what he says, but I would like some proof that grain improves a profile.

KODACHROME BLUE
Hutchcolor may be correct about grain and profiles, but he's wrong about "Kodachrome blue":

On most scanners, Kodachrome® transparencies produce a strong blue or blue-magenta cast, because the yellow dye used in Kodachrome film emulsions appears weaker through typical scanner filters than it does to the human eye.

Wrong. RWG Hunt makes it clear (p229, Reproduction of Colour) why all scanners will see Kodachrome with a blue cast (Hunt was Assistant Director of Research at Kodak, Harrow):

When the viewing conditions consist of projection by tungsten light in a  darkened room, the light form the projectors appears yellowish, and therefore to obtain results that appear grey the picture has to be slightly bluish; this is why the curves of Fig. 14.9(a)… are not even approximately coincident, the blue densities being lower than, and the red densities higher than, the green densities, in order to produce the bluish result required.

Silverfast makes even more of a hash of the explanation of "Kodachrome blue" than does Hutchcolor:

Accordingly the human eye will see more of the yellow spectrum contained in a Kodachrome image than the scanner's CCD. Consequently scanning a Kodachrome transparency with an ICC profile based on a Fuji or Ektachrome IT8 calibration, will produce bluish scans. Only with a dedicated Kodachrome calibration target can correct and original "Kodachrome colors" be achieved.

Even people who should know their stuff, appear ill-informed when it comes to scanning Kodachrome. I'm not trying to belittle their comments, I'm just trying to understand the scanning of Kodachrome (and slides in general) and how it is best done, and misinformation like the above doesn't help.

[guyburns]

I have just come across an article about scanning and gamma:http://photo.bragit.com/scanning/it8tests.shtml

I haven't digested it fully yet, but the author seems to be of the same mind as I am: that for accurate profiling of deep shadows, an increased gamma is desirable. In his update to the article (linked at the bottom of the above webpage) he says:

Since the referred article was written in December 2004, I now recommend to do everything in gamma 2.0, also when inCamera profiles are used. The reason is that it provides a better base for lifting deep shadows.

Then he provides lots of examples. My testing at gamma 1.0, 1.5, 1.8, and 2.2 seemed to suggest that gamma 2.2 was sometimes better than 1.8, but for various reasons I've settled on 1.8. Maybe the optimum lies at 2.0 as "bragit" suggests. Time for more testing!

[dmerger]

Kodachrome GS5: 69.79, -8.84, 3.65
Velvia GS5: 65.89, -1.54, 2.07

When I typed those numbers into PS ...

How do you type these numbers into PS?  I'm using PS CS4, 64 bit, and it allows me to enter whole numbers only.

GS5 COLOUR NUMBERS
The figures you quoted for GS5 colour numbers for my Kodachrome scan and your Velvia scan may not be truly representative of the actual colour numbers of Patch 5. Two reasons:

1. There is quite a bit of variation within each patch. If you move around inside a patch, the colour number change significantly. This is best seen by looking at the histogram of a patch which will show a spread of values.

I set my color picker to a large average number of pixels and get very little variation within each patch.  Also, IMO, using the info data is much more useful for this purpose than the histogram. On a pixel level, I agree there is a much wider variation, due to dye clouds, grain and the inherent difference of averaging.  IMO, that pixel level variation is irrelevant.

Regarding dust and grain, I agree with you about dust and using ICE, but I agree with Hutchcolor about grain.

KODACHROME BLUE
Hutchcolor may be correct about grain and profiles, but he's wrong about "Kodachrome blue":

On most scanners, Kodachrome® transparencies produce a strong blue or blue-magenta cast, because the yellow dye used in Kodachrome film emulsions appears weaker through typical scanner filters than it does to the human eye.

Wrong. RWG Hunt makes it clear (p229, Reproduction of Colour) why all scanners will see Kodachrome with a blue cast ...

...

Even people who should know their stuff, appear ill-informed when it comes to scanning Kodachrome. I'm not trying to belittle their comments, I'm just trying to understand the scanning of Kodachrome (and slides in general) and how it is best done, and misinformation like the above doesn't help.

I disagree with your criticism of Hutchcolor.  It appears that your criticism is because he said "most scanners", not all scanners.  That difference seems inconsequential.  Moreover, unless someone has tested every single model of scanner ever produced, they'd be safer in saying "most scanners", not all scanners. So, IMO, Hutchcolor's use of the words "most scanners" is a positive sign, and certainly doesn't warrant criticism. 

[dmerger]

I have just come across an article about scanning and gamma:http://photo.bragit.com/scanning/it8tests.shtml

Maybe he's correct, but in my experience, as demonstrated by my example scan above, I have no problem using linear data. On the other hand, I have no problem using gamma adjusted data.  So, by all means use gamma adjusted data if it suits you.

So far I've just glimpsed at the linked article.  But one thing jumped out at me.  When he describes setting up his scanner and "Optimizing lamp lightness", he wrote: "The exact lamp setting for my unit is: +8 units overall, plus an additional +6 and +4 units respectively for green and blue."  This approach is contrary to the usual recommendation and contrary to my practice. Is it wise to make color corrections before profiling?  I'll need to read his article more carefully, but a lot of what I've glanced at raises questions.

[guyburns]

How do you type these numbers into PS?  I'm using PS CS4, 64 bit, and it allows me to enter whole numbers only.

I rounded the numbers.

I disagree with your criticism of Hutchcolor.  It appears that your criticism is because he said "most scanners", not all scanners.  That difference seems inconsequential.  Moreover, unless someone has tested every single model of scanner ever produced, they'd be safer in saying "most scanners", not all scanners. So, IMO, Hutchcolor's use of the words "most scanners" is a positive sign, and certainly doesn't warrant criticism.

I should have made myself clearer in my criticism. Hutchcolor's explanation of Kodachrome's blue cast – "because the yellow dye used in Kodachrome film emulsions appears weaker" – is simply wrong. Kodachrome was designed to have a blue cast, and it will scan with a blue cast even if the image is IT8 profiled. Nothing to do with the human eye response being weaker or stronger than scanner sensors. I wasn't criticising his "most scanners" comment, except indirectly by my comment that all scanners will see a Kodachrome blue cast – and they will, unless the scanner manufacturer offers a Kodachrome setting on their scanning software, and that setting accurately compensates for Kodachrome's blue cast. I found, for example, that Vuescan's Kodachrome setting doesn't alter the scan.

[guyburns]

When he describes setting up his scanner and "Optimizing lamp lightness", he wrote: "The exact lamp setting for my unit is: +8 units overall, plus an additional +6 and +4 units respectively for green and blue."  This approach is contrary to the usual recommendation and contrary to my practice. Is it wise to make color corrections before profiling?  I'll need to read his article more carefully, but a lot of what I've glanced at raises questions.

That's what I'm looking for – articles that raise lots of questions. It's only by questioning that you learn. I haven't gone through the entire bragit.com article yet, as I got sidetracked by all the links.

My initial answer to your query: "Is it wise to make color corrections before profiling?" is that it shouldn't matter. The idea of profiling is to correct for errors, so if someone wants to introduce gamma or colour corrections while scanning, it shouldn't make much difference, as long as those same settings are used for all scans. The reason why it may be desirable to introduce corrections while scanning, is to bring the scanned image of the target as close as possible to the real IT8 target. That way, the profiling software has less correction to do. One of the links that bragit.com provides is to computerdarkroom.com, where it states:

Those of you reading this who already own a scanner profiling application… will be wondering if the above procedure for determining the ideal gamma is either necessary or desirable. The simple answer is NO and Yes in that order! The reason it's not necessary is the IT8 calibration will always reproduce grey-scale patch GS11, etc, as per the associated reference data file irrespective of what gamma value you choose to make the original scan with. In effect the IT8 calibration process will produce the optimum Tone Curve.

Sounds reasonable to me. But his explanation of the "Yes" part – is gamma correction desirable, is not at all clear. Something to do with loss of shadow detail in some cases for some scanners.

Getting back to my original post about gamma: I assumed that a setting of Gamma 1 would give similar scans for all scanners. Of course I imagined different colours, different brightnesses, but basically I assumed a similar general look, no matter who made the scanner. It looks like that is a wrong assumption. When I set gamma = 1, the scan is extremely dark – the mean value for the GS11 patch is 48. GS11 should scan in the range 100-115. That's something I didn't realise, and which is not explained anywhere that I could find in the Coca or Argyll documentation. Here's a very clear explanation from computerdarkroom.com (Optimising the Scanner Tone Response Curve):

The purpose of scanning the grey calibration strip [of the] IT8 calibration target… is to find a the ideal Tone Curve or gamma-gradation value for your particular scanner. The simplest approach is to adjust the gamma value so that the grey patch GS11 on the IT8 calibration slide has an average RGB value in the range 100-115. This means scanning the IT8 at different gamma values then selecting the one that is closest to the optimum. You should also find that the average RGB values for patches GS0 (white patch) is in the range 235-250 and GS23 (black patch) is in the range 10-25. In each case it is better to avoid values outside these ranges.

Dean, it looks like your scanner has a different Gamma 1.0 than mine. All this talk from me about needing to vary gamma might come down to the fact that your Gamma 1 may be equivalent to my Gamma 1.8. In your case you see good results at Gamma 1 (GS11 ~100), whereas I need Gamma 1.8 to achieve the same result. If I use Gamma 1, the scan is so far away from what it should be, the profiling introduces small errors at the extremes.

QUES
How can you tell which of our scanners is actually scanning at a true Gamma 1.0? We both have IT8 targets that would be pretty much identical, yet my Gamma 1.0 scan (I'm assuming) is seriously darker than yours. Why? Is my scanner faulty, or is your scanner applying corrections before you are given the ability to adjust?

The only way I can think of to work out which scanner if actually giving true Gamma 1.0 is to go back to the maths:

 Y/Yn = ((L* + 16)/116)3

Where Y/Yn is the relative luminance (Yn is max white), and L* is the brightness value in Lab coordinates – which are available in the data file for each IT8 target. I have just scanned my Velvia target at Gamma 1.0, 2.0 and 2.2 with these results for GS0, GS11 and GS23 (in order for each gamma):

Gamma 1.0 … 235,  40,   1.2
Gamma 2.0 … 244, 100, 15.8
Gamma 2.2 … 245, 109, 20.0

Taking the computerdarkroom.com figures as a guide, that means I should be using Gamma 2.2. It would be interesting to see your readouts for Gamma 1.0.

Now the maths to work out if my Gamma 1.0 is actually gamma = 1.0. Assume that it is. If so, the 0-255 scale is linear would be linear with respect to luminosity and be equivalent to the "Y" values in the formula, with Yn being the maximum white for the IT8 target (GS0). From the IT8 data file, the L* values are:

GS0 = 92.18
GS11 = 41.95

Maximum white in the Velvia IT8 target has an L* value of 92.18. Plugging this into the formula gives: Y/Yn = 0.811. The maximum luminance of the Velvia brightest white is actually only 81.1% of reference white (I'm not sure what that is defined as). But as this is all relative, it doesn't matter anyway.

What is the relative luminance of GS11? It is defined as having an L* value of 41.95, which gives Y/Yn = 0.125.

The luminance ratio of GS11/GS0 is therefore 0.125/0.811 = 0.154. If my scanner is truly scanning at Gamma 1.0, then the RGB value of GS11 (measured in Photoshop as 40 – see above) should be 0.154 times the RGB value of GS0 (measured as 235):

Measured GS11: 40
Theoretical GS11: 0.154 x 235 = 36.

Indicating that my scanner when set to Gamma 1.0 is giving a close match to a linear series of luminance values (I consider within 10% close, given all the inaccuracies involved). A graph of the results for several greyscale patches gave a straight line (see attachment). Dean, it would informative if you could run through the same calculations for your Gamma 1.0 scan.

My understanding of colour theory is only superficial, so there may be errors in the above analysis. Anyone care to comment? What I'd like explained is: why my Gamma 1.0 scan appears much too dark on my monitor. My theory is:

1. It is a true Gamma 1.0 scan, meaning that linear values of luminance are being saved to the image file.

2. In Photoshop, my default colour space is sRGB, and that is the space in which the image is being shown. sRGB has a gamma of 2.2, meaning the input-output relationship is a power-law of the form Out = In2.2 (see attached graph).

3. If the above are true, then my image is going to have a lot of dark areas because each RGB value will be mapped downwards. Only if the profile has a linear characteristic matching the RGB data will the image display properly.

To confirm the above, I generated a linear sRGB profile following these instructions (Making a Linear IC Profile): http://fnordware.blogspot.com/2008/05/making-linear-icc-profile.html. I then applied the profile to my supposed linear scan and … it appeared similar to my IT8 scans with gammas of 1.8 and 2.2. This has suggested to me a test for whether or not an image has linear gamma: Open the image in PS and apply a linear sRGB profile. If the image is way too bright, then you do not have a Gamma 1.0 image.

I have uploaded a zip file called Gamma 1 Test Documents to http://www.mediafire.com/?thogddgfozxi2 in case anyone wants to play around and offer comments. The file contains:

• Gamma 1.0 Plot (image as attached here and Grapher version for opening on Mac);
• Gamma 1.0.tif (a linear IT8 Kodachrome scan);
• Linear sRGB IEC61966.icc ( a linear sRGB profile)

[guyburns]

The bragit.com articles were interesting as far as altering gamma was concerned, but otherwise were not very informative. You cannot base a conclusion about scanning slides on the results when applied to three slides. I have 20 reference slides, each scanned and edited scores of times and I still haven't come up with a reliable method of scanning and editing to obtain optimum results – but I'm getting close. Another problem with bragit.com is that the author comes up with no overall method that might work. Sometimes he uses gamma 1.0, other times gamma 2.0. A bit of a dog's breakfast, unfortunately.

The author at computerdarkroom.com is more informative, but lacks justification for his conclusions. Why should gamma be changed so that GS11 is in the range 100-115? Where did those numbers come from?

One idea was presented by bragit.com that I hadn't considered so far: the editing colour space. All my editing has been in the IT8 profile colour space, whereas he converts to Adobe RGB, saying that shadows are best lifted in the IT8 space, but colour editing is best done in Adobe RGB.

[dmerger]

Here's the linear version of the IT8 slide I posted above. I merely reduced the size and saved as a jpeg.  Edit: Of course, I also had to change it to 8 bit.

Why are you using sRGB as your working color space?  Wouldn't aRGB or, perhaps better yet, ProPhoto be a better choice?

In my opinion, the scanning info on Computer Darkroom is, for the most part, just advertisement for SilverFast.  I'm not inclined to comment further on info from that site.  As for the bragit info generally, maybe what he writes is accurate for his scanner and workflow, but doesn't seem to coincide with my experience with my scanner.

As for when to do your gamma, color and other such adjustments, I've already said about all I can say, which is I do not have problems with linear.  Worth considering, however, is digital cameras use CCDs just like your scanner, and the clear consensus is it is best to process their raw files, which are linear, with something like ACR or Lightroom, both of which I believe use linear data internally.    

Don't be too quick to dismiss the info from HutchColor.  Bear in mind that whether Kodachrome has a blue cast depends on the light source.  Hunt was talking about projecting Kodachrome with a tungsten light source.  HutchColor was talking about scanning.  Maybe HutchColor is wrong, but maybe it's possible to reconcile the two statements. In any event, both agree that Kodachrome has a blue cast when it's scanned. Is the reason why so important for the present purposes?

I guess I'm not sure what you hope to accomplish by creating a Kodachrome profile.  It now seems like you want your profile to accurately reproduce the colors of Kodachrome, including a blue color cast.  (Note, as I mentioned above, that the blue color cast is partly a function of the light source.  In other words, perhaps you could say that Velvia has a yellow color cast if all you did was view it projected with tungsten light.)  I thought you were trying to create a profile that didn't produce a blue color cast, but I'm not so sure any more.  

[crames]

Hi Guy,

Gamma in scanning was necessary in the old days when scanners only output 8 bits. Internally, the scanner ADCs were putting out more than 8 bits, linear. Gamma served to compress the higher-bit "raw" scan data to fit into only 8 bits of output.

If you read the Hutch Color scanning info carefully you will see that the exercise of applying different gammas was to optimize the 8-bit output.

Most desktop scanners nowadays allow saving the full internal high-bit linear data, making it unnecessary to apply gamma (which loses data). The linear high-bit output of a scanner is the best (most complete) data that you can get.

"Theoretically," the unmolested linear high-bit scans should be best for profiling. An input profile will normally be referenced to the XYZ PCS (profile connection space), which is a linear space. One of the first things that profiling software must do is to linearize the target data to the reference. If the target data is gamma-compressed, it just gives the profiling software more work to do as it will have to calculate a function to reverse the gamma-compression. Plus, many levels have been lost as a result of the gamma-compress-decompress process.

So linear target scans should be at least as good as, if not better than, gamma-compressed scans. Why are the linear profiles the worst in your tests?

I downloaded your reference scans and profiles to see what was going on, but there is a problem - your reference scans are all 8-bit. Of course this will favor scans that have been gamma-compressed before truncation to 8-bits. Linear scans in 8-bit are guaranteed to be posterized. Can you make the 16-bit versions available for download?

Rgds,

[guyburns]

Crames – just a quick reply. From memory, the scans from which I generated the profiles were 2000 dpi 16-bit. The scans I uploaded were probably reduced in size to make them smaller. I'll upload the full-resolution scans today.

P.S. I finally finished Hunt. Did you see my reply to the thread where you asked about the effect of dim surrounds when editing in dark surrounds (or vice versa)?

[crames]

Crames – just a quick reply. From memory, the scans from which I generated the profiles were 2000 dpi 16-bit. The scans I uploaded were probably reduced in size to make them smaller. I'll upload the full-resolution scans today.

Thanks. Small is OK but keep the full 16-bit depth.

Another thing to consider is the way Photoshop displays images with 16-bit linear profiles. Photoshop can display linear images with heavy posterization even when the underlying data is smooth, but the posterization will go away once the image is converted to a gamma space.

P.S. I finally finished Hunt. Did you see my reply to the thread where you asked about the effect of dim surrounds when editing in dark surrounds (or vice versa)?

Thanks for the reply and sorry for the delay - I will try to respond shortly.

[guyburns]

I have uploaded the 16-bit scans to a folder called Kodachrome IT8 Scans 16-bit, 57 MB, which can be accessed here: http://www.mediafire.com/?thogddgfozxi2

I have revisited Gamma = 1 scans and have compared the scanned values of the darker grayscale patches (GS20-23) with what they should have been according to the L* values. The results were a bit of a surprise. The first figure is the value shown by the histogram after the target was scanned; the second figure in brackets is the L* value from the IT8 data file, set to the range 0-255 by the formula RGB = 255L* /903.3 (the formula which applies when L* is less than 8, according to Hunt page 110):

G20 … 1.49  (1.20)
G21 … 1.33  (0.79)
G22 … 1.33  (0.30)
G23 … 1.32  (0.14)

The surprise wasn't the difference between scanned and theoretical – the surprise was the constant high black level for the last three patches. Under a strong light I could see the difference between G21 and G22, but G22 and 23 looked the same. The blacks appeared to be beyond the capability of the scanner. So I thought I'd scan the slide using the POS setting instead of the Kodachrome setting, as that should give a purer result (no Kodachrome conversion):

G20 … 1.07  (1.20)
G21 … 1.00  (0.79)
G22 … 0.98  (0.30)
G23 … 0.99  (0.14)

This is what is happening: I could clearly see the change in colour between the Kodachrome and POS scans: the Kodachrome has a yellow cast compared to the POS. Yellow seems to sweep across the entire slide when I changed between the two. And this yellow cast washes out the densest blacks. This throws up a quandry:

1. The use of ICE to remove dust via infrared detection is a huge plus for the Coolscan under NikonScan. It works superbly for Kodachrome slides, hardly affecting the image in almost all cases, and in the few cases where it does bad things, I have a simple workaround. ICE is a must-have for me.

2. Well then, if the Kodachrome setting causes problems with the densest blacks, why not use ICE under the POS setting? IT8 profiling should take care of the colours. Unfortunately, when scanning under POS, ICE uses a stronger version of dust removal, and this stronger version can't be used with Kodachrome because ICE interprets something in Kodachrome as dust and removes it. ICE+POS (for a Kodachrome slide) means wrong colours by about 5-10 RGB values; whereas ICE for a Kodachrome slide with the Kodachrome setting has no effect on colour.

3. So I can't use the POS setting because ICE (under POS) is too rough with Kodachrome; but the Kodachrome setting slightly decreases the density of the densest blacks, resulting in the last three being blocked.

NikonScan should have incorporated a feature to vary the ICE strength.

And nobody should suggest that I try SilverFast. I have, and its implementation of ICE when driving the Coolscan is pretty abysmal.

If anyone would like to see the result of the four combinations of ICE and POS on a Kodachrome target, check out the zip file called Kodachrome IT8 ICE & POS Comparison (31 MB) available for download from the link given above.

[crames]

I have uploaded the 16-bit scans to a folder called Kodachrome IT8 Scans 16-bit, 57 MB, which can be accessed here: http://www.mediafire.com/?thogddgfozxi2

I was hoping to see the ref 05 scans in 16 bit, but the IT8 Scans 16-bit are definitely much smoother.

Can't comment on the ICE/NikonScan issues as I don't have a Coolscan. What is "POS?"

[guyburns]

POS is Nikon's shorthand for "Positive" – every slide type except Kodachrome.

[guyburns]

I was hoping to see the ref 05 scans in 16 bit, but the IT8 Scans 16-bit are definitely much smoother."

I'll upload some of the reference scans in 16-bit if you want to play around.

Try as I might, I cannot get a Gamma 1.0 scan of a high-contrast slide to look as good in the shadows as a Gamma 1.8 scan. And in my experience, it's the shadow area that is very important for a slide to look good on screen. Whether it's my scanner or Argyll I don't know. Will post the results for all to see as soon as I am confident of the results. There's no particular reason I chose gamma 1.8. It was just one of a range of values I was experimenting with.

I've been wondering if there is an optimum gamma (other than 1), so I've been playing around with some equations to work out how closely a gamma curve matches the L* curve. A close match would mean that when profiling the scan in Lab coordinates, the errors would be minimized. I have attached a plot showing the gamma 2.2 and the L* function, and a third curve showing the errors between the two. By plugging in a range of gamma values, it turns out that the optimum match between gamma and L* occurs around gamma 2.5.

More experimenting coming up.