Color Space Choices for Nikon 5000 Scans

[stlsailor]

Using Nikon Scan 4 on a Super Coolscan 5000, and assuming 16-bit scanning, there are several color space choices. The most likely choices seem to be Adobe RGB, Wide Gamut RGB, and Wide Gamut RGB (Compensated).

I'd think there are three objectives:

(1) Scan for archival purposes in a color space that most closely approximates the colors that the scanner can capture from the positive or negative.
(2) Work in a color space that is designed for neutral grays.
(3) Capture in a color space that is likely to be supported well into the future.

Beyond family record photos for which sRGB would probably be sufficient, it seems the most likely choices for color space for scanning and corresponding working space in PS CS5 are:

(1) Scan in Adobe RGB; work in PS in Adobe RGB. You have consistency and aRGB is good enough for many commercial processes.

(2) Scan in Wide Gamut or Wide Gamut (compensated); work in PS in Wide Gamut. It is not clear how Wide Gamut (compensated) maps to Wide Gamut in PS or how quickly Wide Gamut will be completely displaced by ProPhoto RGB.

(3) Scan in Wide Gamut or Wide Gamut (compensated), work in PS in ProPhoto RGB.

I am not actually yet convinced that any color space larger than aRGB is a necessity, but I've got several thousand photos to scan and don't want to have to redo it later, and will probably work in ProPhoto for DSLR RAW images, so I'd probably just scan in that if I could.


Dale

[stlsailor]

An additional note:

I scanned a group of images four times -- (1) sRGB 8 bit, (2) Adobe RGB 8-bit, (3) Adobe RGB 16-bit, and (4) Wide Gamut compensated 16-bit. I viewed the images on a calibrated monitor.


STEP ONE: I looked at the histogram on all the scans.

aRGB-16 gave the widest range. sRGB-8 and aRGB-8 gave slightly narrower ranges. WGc/16 gave the narrowest range.


STEP TWO: I opened all four images in PS CS5, created a Curves layer, and hit the auto button.

The histogram for WGC-16 had banding in the extreme left side of the histogram. For aRGB-16 it had no banding in the histogram. The two 8-bit images had banding as expected.

aRGB-16 had the most accurate color based on the original transparency, followed closely by aRGB-8, though both were slightly oversaturated. WGC-16 were undersaturated. sRGB-8 was consistently worse.

WGc-16 had the most visible shadow detail without enlarging. However it also had significant noise in the underexposed shadow area whereas aRGB-16 and aRGB-8 had virtually no noise. I do not understand why the color space choice would affect noise.

The differences were very significant where color fading had occurred; otherwise they were much less significant.


STEP THREE: I scanned several of the transparencies at 16-bit with scanner RGB and created duplicates. I PS CS5 I assigned aRGB to one; WGc to the other. Again I hit the auto button on curves and the aRGB had significantly more accurate color.

My conclusion at this point is that with several thousand slides to scan, the least work to get the most accurate color would be to scan 16-bit using Adobe RGB.

Dale

[andrewrodney]

Originally Posted by stlsailor

(1) Scan for archival purposes in a color space that most closely approximates the colors that the scanner can capture from the positive or negative.

Then you’d want to scan into “scanner RGB”, its native color space, described by an input profile of that device. No such option in the software you’re using?

I can tell you that you absolutely want to scan high bit (16-bit although its unlikely that’s the bit depth of the scanner). And you want a working space if that’s the only option that’s wider than sRGB and probably Adobe RGB (1998). Its quite likely the scanner’s native color space is much larger than either of those two working spaces. Again, the native space is the “purest” capture of data at this stage. At some point, you’ll likely want to convert it into a working space for editing.

[stlsailor]

Then you’d want to scan into “scanner RGB”, its native color space, described by an input profile of that device. No such option in the software you’re using?

That is what I would have thought. However I'm thinking that's not true for two reasons. First, the Nikon Scan 4 manual says ""This profile replicates the color space achieved when scanning with Nikon CMS off. Its main purpose is to allow the LCH editor and Unsharp Mask tools, which are not available when Nikon CMS is off, to be used to edit the colors produced by the scanner. 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." The second reason is that when I scanned in Scanner RGB and assigned either ProPhoto or Adobe RGB as the color space, the results were not nearly as good as scanning directly into Adobe RGB.

I can tell you that you absolutely want to scan high bit (16-bit although its unlikely that’s the bit depth of the scanner).

Yes, after looking at the sample scans I'd have to agree. In some cases the 8-bit is almost as good as the 16-bit, but in other cases it's not. In any case the histogram makes the data loss fairly clear.

And you want a working space if that’s the only option that’s wider than sRGB and probably Adobe RGB (1998). Its quite likely the scanner’s native color space is much larger than either of those two working spaces. Again, the native space is the “purest” capture of data at this stage. At some point, you’ll likely want to convert it into a working space for editing.

sRGB was consistently the worst of all my sample scans, so I've ruled that out. I would have expected Wide Gamut or Wide Gamut compensated to have produce better results, but Adobe RGB seemed to. I thought, too, and still do, that the scanner's native color space is wider than Adobe RGB, but that is based on no evidence. I haven't been able to find an explicit comparison.

I went into this expecting that Wide Gamut compensated would produce the best results. So far Adobe RGB seems to, which was a surprise. It may be with extensive editing that I can get more out of Wide Gamut, but with several thousand slides there's not time for extensive editing.

Dale

[andrewrodney]

Originally Posted by stlsailor

The second reason is that when I scanned in Scanner RGB and assigned either ProPhoto or Adobe RGB as the color space, the results were not nearly as good as scanning directly into Adobe RGB.

You’d never do that. You’d assign the scanner profile. Ideally, the software would embed this. Ideally you’d build your own scanner profile too. Part of the issue may be the scanner driver (Nikon kind of sucks when it comes to color management). Assuming you don’t want to switch, might be best to use either Adobe RGB (1998) or maybe ProPhoto RGB which I know is vastly larger than the scanner native color space. The alternative is to find a driver that has a better COLOR MANAGEMENT idea of a workflow, something like SilverFast.

[stlsailor]

You’d never do that. <scan in scanner RGB and assign a color space in PS> You’d assign the scanner profile. Ideally, the software would embed this.

I tested it because on some forums it has been suggested. My results bear out what you're saying. It's not a good approach. It doesn't appear that NS4 embeds a scanner profile, though. So this option is off the table.

Ideally you’d build your own scanner profile too. Part of the issue may be the scanner driver (Nikon kind of sucks when it comes to color management). Assuming you don’t want to switch, might be best to use either Adobe RGB (1998) or maybe ProPhoto RGB which I know is vastly larger than the scanner native color space. The alternative is to find a driver that has a better COLOR MANAGEMENT idea of a workflow, something like SilverFast.

I'm not ruling out VueScan or SilverFast. Some people who use them seem to like them. Others don't like them much at all. I'm willing to spend the money if I see a clear benefit. Vuescan doesn't seem to differentiate between Kodachromes and other positives in their ICE selections which NS4 does. I haven't been able to find a list of what color spaces it supports. Silverfast seems overly expensive.

Adobe RGB (1998) seems to produce better color than Wide Gamut compensated (which is probably NS4's closest equivalent to ProPhotoRGB). I'm not sure why. I haven't yet tried converting either one to ProPhotoRGB, but since at least Adobe RGB is a narrower color space, I don't know that there's any benefit to testing it other than for Wide Gamut.

Dale

[TommyO]

Stlsailor,
It sounds like you have a good feel for what you're doing and a good working knowledge of color management. So, my 2cents would be.... I tend to look at past experiences to guide me on projects like this. When scanning large numbers of images simply for archival, I like to keep it somewhat simple. Scan at a reasonably high bit depth and in a large well supported color space. I know it's not likely I will ever access or edit very many of these images. But, I may chose to run some type of batch process on them 10-20 years from now and would prefer it run without any hiccups. At that point in time, who knows what technology will be available, but I'm confident it will be far superior to todays. Bit depth and color spaces from this era will be considered ancient if not irrelevant. If I were going to be editing these images in the next few years, I would be more concerned about the specifics. I often break out certain images I want to retouch soon and scan them differently, in effect doing two batches, one for archival one for retouch.

I would agree that the Wide Gamut color spaces are likely a Nikon creation and would avoid scanning in that space. Is ProPhoto RGB too broad?... not likely. In fact, Adobe engineers (whom have an excellent reputation) decided to use that as the working color space within Adobe Camera Raw. ACR works in ProPhoto RGB with a linear gamma prior to saving in your color space of choice.

So, I guess what I'm saying is... for archival, keep it simple, keep it accurate, keep it standardized. Focus more on your archival workflow so that all those scans will still be intact 20 years from now. Do a separate scan for any images you may choose to edit and print in the near future.

[stlsailor]

TommyO,

I appreciate your thoughts, especially the philosophy of keeping it simple when you've got a big workload. I'm open ears.

I hadn't thought of differentiating archival from current images in the way you suggest. It makes sense. Given that, here's what I'm seeing as a high level archival workflow omitting metadata and cataloging considerations for simplicity.

1- Standard archival scan at 2400 dpi 16-bit in Nikon Adobe RGB with only Digital ICE creating TIFF_TEMP.

2- Open in PS, convert color space to standard Adobe RGB, then save as archival image TIFF_ARCHIVE for later offline storage. The temporary image in the above step is no longer needed.

3- Do basic editing in PS as needed (capture sharpen, tonal, color, noise), but don't do intensive editing now. Save the layered TIFF as the new TIFF_MASTER.

4- Pick/Reject/Rate in LR3. Delete rejects. Put an image on a list to rescan with different parameters (e.g. 4000 dpi) if

• it is going to be worked on any time soon
• is a high star rated image with intrinsic value beyond being simply a family snapshot
• is likely at some point be enlarged greater than 8 x 10
• will have a small portion cropped and enlarged.

A few thoughts.

Most scanned images appear to need some PS work, even if only auto. That's why I haven't put a Lightroom step in the workflow.

Always scanning at 16-bit simplifies the workflow and considers your comments about the future. (A friend cautioned me, though, whatever we do today will look quaint in the future just like old images do today, so don't cause myself too much work.)

I expect to use ProPhoto RGB for DSLR RAW (I recently upgraded to PS CS5). But scanning in Wide Gamut and converting to ProPhoto didn't seem to capture color as accurately and simply as Adobe RGB. Nikon Adobe RGB (1998) is almost identical to Adobe RGB (1998) based on the histograms, but perhaps standardization is still worth the conversion step. Perhaps I could automate it in PS?

I'm also considering whether to leave the master image in TIFF format or convert to PSD (or to DNG but I haven't seen a reason for that)?

I'd rather do the scans (steps 1-2) independently of steps 3-4. But until I've done basic tonal corrections and color restoration I don't know if they are picks or not, or if I want to rescan them with different parameters. I guess I still could do the two functions as independent workflows though.

Given that as the strawman, does that accurately capture your thoughts on color space and bit depth, or is there something you'd suggest considering changing?

Dale

[TommyO]

Stlsailor,

I like the fact that the workflow is defined, and that it is fairly strait-forward. I'm in agreement that you should focus on steps 1 & 2 independent of 3 & 4.

And, of course, some other modifications could depend on how many scans we're talking about. You can add up the time spent per image and let that influence the workflow as well, versus what you really want to spend per image. I like the workflow for small numbers of scans, but think it could be lengthy for large numbers.

For example, step 2: if doing a large number of scans, I wonder if step 2 should only be performed if it can be run as a batch command.

Also, step 3: I know you mentioned this would allow you to make some decisions about the image. However, if it cannot be automated with a script, it could also be quite time consuming. Hence, possibly you may have to use your eyes during step 4 to make some judgments. (It doesn't take many scans before the brain works better than Photoshop in predetermining what can be done with an image.)

I would look at standardizing on AdobeRGB if you can automate it, as you suggested.

I'm on the fence regarding TIFF, PSD or DNG. I'm thinking PSD, until at some point in the future it is not supported (not likely). At that time run a batch conversion to the latest format. We could see newer versions of PSD require some conversion of older versions; again a major batch convert and your done.

Again, it boils down to the quantity. The times I have scanned 100's of images, I've been glad I simplified the workflow. I have not gone back to very many of those to edit... maybe 2 per 100 at the most. The rest just sit there for safe keeping. It's easy to see that if I ever wanted to restore one today, I'm confident today's software could do a much better job than what I had 7 years ago. So, looking ahead, I can't imagine your regretting not doing more restoration of them now. Ten years from now it may be you can batch restore nearly all of them with one click.

Hopefully, Andrew or others will chime in and give their thoughts as well. Otherwise, best of luck and let us know your final thoughts.

[andrewrodney]

Originally Posted by stlsailor

I expect to use ProPhoto RGB for DSLR RAW (I recently upgraded to PS CS5). But scanning in Wide Gamut and converting to ProPhoto didn't seem to capture color as accurately and simply as Adobe RGB. Nikon Adobe RGB (1998) is almost identical to Adobe RGB (1998) based on the histograms, but perhaps standardization is still worth the conversion step. Perhaps I could automate it in PS?

Its pointless to go “Wide Gamut” (not sure what that is) to ProPhoto RGB. I’m assuming Wide Gamut is an RGB working space like ProPhoto but with different primaries defining it and hence its gamut. Again, the best archival approach would be to scan and tag in the native color space of the scanner. Its not too large or too small, it IS what the scanner is producing. Then, tomorrow or in 20 years, you can convert to a working space. Keep color conversions to a minimum. There’s really no conversion when you scan into the space of the scanner at this point.

[stlsailor]

Again, the best archival approach would be to scan and tag in the native color space of the scanner. Its not too large or too small, it IS what the scanner is producing. Then, tomorrow or in 20 years, you can convert to a working space. Keep color conversions to a minimum. There’s really no conversion when you scan into the space of the scanner at this point.

Nikon Scan 4 has an option to set the color space to Scanner RGB. However, as I read the manual , it doesn't actually embed the color space--only uses it within the Nikon software if you edit there. Other software doesn't have that color space as an option to recognize it properly. PS sees it as sRGB. I like what you're saying, just not sure how to practically do it.

I like the workflow for small numbers of scans, but think it could be lengthy for large numbers...if it [step 3] cannot be automated with a script, it could also be quite time consuming. Hence, possibly you may have to use your eyes during step 4 to make some judgments.

Time consuming is a big concern of mine. Yet to use them at all, basic tonal and color correction is required. In most instances simply opening up curves and hitting the auto button does well at a basic level. If PS won't let me automate that, then I'll probably try doing step 4 by eye as you suggest.

I'm on the fence regarding TIFF, PSD or DNG. I'm thinking PSD, until at some point in the future it is not supported (not likely).

I've read some just this morning that also leans towards PSD as an archival format, though it doesn't seem to be a deal-breaker either way.

Again, it boils down to the quantity. The times I have scanned 100's of images, I've been glad I simplified the workflow. I have not gone back to very many of those to edit... maybe 2 per 100 at the most. The rest just sit there for safe keeping.

These comments and your earlier ones, are helping me think about this a bit differently--and seeing the value in separating the two phases of scanning and editing. What works best may depend on whether I find I can automate auto curves or not. I'll look at that soon and let you know what I find out.

Dale

[andrewrodney]

Originally Posted by stlsailor

Nikon Scan 4 has an option to set the color space to Scanner RGB. However, as I read the manual , it doesn't actually embed the color space--only uses it within the Nikon software if you edit there. Other software doesn't have that color space as an option to recognize it properly. PS sees it as sRGB. I like what you're saying, just not sure how to practically do it.

PS “sees” it as sRGB due to how you have your Color Settings setup (RGB working space set to sRGB). Untagged documents are assumed to be in whatever working space you set there. But unless you can get hold of the scanner profile, its moot (told you Nikon can be clueless about color management).

[kav]

16 bit isn't always necessarily worthwhile. Adobe RGB will provide the fewest headaches. Wider gamuts can introduce a lot of issues and I don't think you'll see any kind of gain in your final printed results. Computer monitors also won't accurately display things like prophoto rgb.

edit: I hadn't noticed the availability of the scanner's profile as an output option. It's probably the safest as that means it isn't being converted.

[stlsailor]

PS “sees” it as sRGB due to how you have your Color Settings setup (RGB working space set to sRGB). Untagged documents are assumed to be in whatever working space you set there. But unless you can get hold of the scanner profile, its moot (told you Nikon can be clueless about color management).

The scannerRGB image shows as sRGB in Bridge before I open it in PS. Some forum posts say that's due to a problem with untagged images in Windows. I don't know if that's true or not. I do know when I open it in PS with ProPhotoRGB set as the working space I get a message that the embedded color profile sRGB IEC61966-2.1 does not match the ProPhotoRGB working space.

(My working space in PS had reverted to sRGB earlier I found, probably due to a system crash, but I reset it and confirmed the above behavior.) So I don't know how PS does the conversion on what should be an untagged file that is passed to it as sRGB (according to the documentation Nikon Scan 4 doesn't embed a profile when scanned in scanner RGB).

Perhaps I should stay away from it as an unknown quantity, but there are two considerations. One is that adding a curves layer with auto applied came closer to the actual slide color than the alternatives I tried. Hmmm...

The other consideration is that several people have said not to apply any scanner adjustments to get what the scanner sees. However what the scanner sees is far darker than what is on the slide until some adjustments are done. It makes me wonder if that advice is sound or not.

edit: I hadn't noticed the availability of the scanner's profile as an output option. It's probably the safest as that means it isn't being converted.

When Windows shows it incorrectly as sRGB then I'm not sure if I'm actually getting the scanner profile, or how PS converts it if I am. In theory, though, this would make sense.

It appears that I could get VueScan and an IT8 target and create a scanner profile. However Nikon Scan 4 already selects a device/film input profile automatically. It just gives you the option to turn CMS on and select a color space to convert to, or leave CMS off -- in which case you get the untagged image seen as sRGB as described above. That at least is how I understand the documentation.

16 bit isn't always necessarily worthwhile. Adobe RGB will provide the fewest headaches. Wider gamuts can introduce a lot of issues and I don't think you'll see any kind of gain in your final printed results. Computer monitors also won't accurately display things like prophoto rgb.

I do have to wonder at what point I go beyond the point of diminishing returns. What kind of issues do wide gamuts introduce (other than possible banding on 8-bit scans)?

Why do you say 16-bit isn't always necessarily worthwhile? I'd love to scan at 8-bits and get the attendant smaller file sizes. Two concerns have made me hesitate. One is the fact that some of the old slides and negatives have color casts or fading for which correction could cause banding based on what I read. The other is that the color in my 8-bit images has been less accurate...BUT...since I found the PS working space had lost its setting unbeknownst to me, I need to retest to confirm whether this is actually true or not. PLUS I've only scanned a few samples so this is more theory than wide experience. In your experience has 8-bit been sufficient most of the time?

[kav]

Originally Posted by stlsailor

The scannerRGB image shows as sRGB in Bridge before I open it in PS. Some forum posts say that's due to a problem with untagged images in Windows. I don't know if that's true or not. I do know when I open it in PS with ProPhotoRGB set as the working space I get a message that the embedded color profile sRGB IEC61966-2.1 does not match the ProPhotoRGB working space.

(My working space in PS had reverted to sRGB earlier I found, probably due to a system crash, but I reset it and confirmed the above behavior.) So I don't know how PS does the conversion on what should be an untagged file that is passed to it as sRGB (according to the documentation Nikon Scan 4 doesn't embed a profile when scanned in scanner RGB).

Perhaps I should stay away from it as an unknown quantity, but there are two considerations. One is that adding a curves layer with auto applied came closer to the actual slide color than the alternatives I tried. Hmmm...

The other consideration is that several people have said not to apply any scanner adjustments to get what the scanner sees. However what the scanner sees is far darker than what is on the slide until some adjustments are done. It makes me wonder if that advice is sound or not.

When Windows shows it incorrectly as sRGB then I'm not sure if I'm actually getting the scanner profile, or how PS converts it if I am. In theory, though, this would make sense.

It appears that I could get VueScan and an IT8 target and create a scanner profile. However Nikon Scan 4 already selects a device/film input profile automatically. It just gives you the option to turn CMS on and select a color space to convert to, or leave CMS off -- in which case you get the untagged image seen as sRGB as described above. That at least is how I understand the documentation.

I do have to wonder at what point I go beyond the point of diminishing returns. What kind of issues do wide gamuts introduce (other than possible banding on 8-bit scans)?

Why do you say 16-bit isn't always necessarily worthwhile? I'd love to scan at 8-bits and get the attendant smaller file sizes. Two concerns have made me hesitate. One is the fact that some of the old slides and negatives have color casts or fading for which correction could cause banding based on what I read. The other is that the color in my 8-bit images has been less accurate...BUT...since I found the PS working space had lost its setting unbeknownst to me, I need to retest to confirm whether this is actually true or not. PLUS I've only scanned a few samples so this is more theory than wide experience. In your experience has 8-bit been sufficient most of the time?

You could test it but a lot of consumer model scanners won't necessarily be much better by selecting 16 bit output. With old scans I often just select it on tough ones or up it in photoshop when I have to flatten adjustment layers. To see what I mean output a scan in 16 bit mode that requires the heaviest adjustment possible. Open it into photoshop. Create adjustment layers and duplicate the document twice. Flatten one while still in 16 bit mode. Drop one to 8 bits and flatten. Drop the third to 8 bits then put it back to 16 via a separate command, then flatten. Compare the 3. It'll show you just how much extra flexibility the scanner is giving you at a 16 bit output vs. 8 as the one which went 16=>8=>16 only benefits from photoshop's math and not extra data in the scan.

[andrewrodney]

Originally Posted by stlsailor

The scannerRGB image shows as sRGB in Bridge before I open it in PS.

Then the scanner is tagging it, either with a true ICC profile or EXIF data. IF the color appearance looks good in sRGB, matches what you saw in the scanner software, well its feeding you sRGB which isn’t good at all!

Some forum posts say that's due to a problem with untagged images in Windows. I don't know if that's true or not.

But the above makes it sound like its not untagged.

I do know when I open it in PS with ProPhotoRGB set as the working space I get a message that the embedded color profile sRGB IEC61966-2.1 does not match the ProPhotoRGB working space.

Again proof that the scan is at least embedded with sRGB so it probably is sRGB unless it doesn’t match what you saw when scanning it. Then the question becomes why is the scanning software tagging it as such.

The other consideration is that several people have said not to apply any scanner adjustments to get what the scanner sees.

Makes zero sense to me, based on the dozens of scanners I’ve used over the decades (none however Nikon). Like processing raw data, the scanner driver should provide the best possible color appearance possible. Now you can scan “flat” or zero everything out, send high bit data to Photoshop and do all the corrections there. The quality would be the same doing the work in either place but it should be far faster to scan the data as you desire than fix it later in Photoshop. Most go the “scan flat, fix in Photoshop“ route when they have poor quality controls in their scanning software. The lesson is, use good software. Is nearly as important as the scanner hardware if cranking out scans is of importance. Otherwise yes, get the high bit data out of the crappy scanner software and do the equivalent work in Photoshop (slower).

I do have to wonder at what point I go beyond the point of diminishing returns. What kind of issues do wide gamuts introduce (other than possible banding on 8-bit scans)?

Wider gamut is totally different from bit depth. The wider the gamut, the move need for higher bit depth anyway.

Why do you say 16-bit isn't always necessarily worthwhile?

I totally disagree with that statement. Why do scanners, cameras, Photoshop and other software and some newer printers support high bit data? There’s a reason (see: http://www.digitalphotopro.com/gear/...-decision.html).

[stlsailor]

You could test it but a lot of consumer model scanners won't necessarily be much better by selecting 16 bit output.

I'm using a Nikon 5000 film scanner, whatever category that fits into.

Like processing raw data, the scanner driver should provide the best possible color appearance possible. Now you can scan “flat” or zero everything out, send high bit data to Photoshop and do all the corrections there. The quality would be the same doing the work in either place but it should be far faster to scan the data as you desire than fix it later in Photoshop. Most go the “scan flat, fix in Photoshop“ route when they have poor quality controls in their scanning software. The lesson is, use good software.

The common thread seems to be that the quality would be the same doing the work in either place. The argument I've heard for doing it in Photoshop is that you have an unaltered archive image. I have to admit that I've wondered how an unaltered underexposed or faded archive image that needs lots of adjustment is superior to a more properly exposed one. Speed is probably the most significant issue. I think I'll run a test doing some of the adjustments in the software. What do you consider good software?

I totally disagree with that statement. Why do scanners, cameras, Photoshop and other software and some newer printers support high bit data? There’s a reason (see: http://www.digitalphotopro.com/gear/...-decision.html).

Most of what I've read recently has argued for 16-bit (and interrelatedly using color spaces of at least Adobe RGB or even better ProPhoto RGB), but I've seen nothing as well-written or comprehensive as your article here. Thanks for pointing it out.

Going 16-bit seems to leave the following options:

OPTION ONE

First, as you said previously, "the best archival approach would be to scan and tag in the native color space of the scanner. Its not too large or too small, it IS what the scanner is producing." Makes sense and case closed except for the fact that the scanner RGB file is coming across as sRGB. So we ask what does this mean?

As you said earlier, "the scanner is tagging it, either with a true ICC profile or EXIF data. IF the color appearance looks good in sRGB, matches what you saw in the scanner software, well its feeding you sRGB which isn’t good at all!"

Actually it doesn't look that good in sRGB or match the original slide very well. Also, according to the manual, scanner RGB doesn't embed a profile. Therefore, it sounds like it may be simply being tagged erroneously in EXIF data. Does that make sense? If so, that raises two questions:

• First, how to confirm if that's the case
• Second, assuming it is, what the optimal working space for it would be if there is one?

A device profile is used automatically by Nikon Scan 4, but if correct color space information is not passed, I don't know how that information can be used.

OPTION TWO

Second, scan in Wide Gamut RGB and convert to ProPhoto RGB. You said earlier "Its pointless to go “Wide Gamut” (not sure what that is) to ProPhoto RGB."

OPTION THREE

Third, scan in Nikon Adobe RGB (1998) and convert in PS to Adobe RGB (1998) which the histograms show to be almost identical.

OPTION FOUR

Fourth, it appears that VueScan is a reasonably priced program that will generate a device profile and use that to scan into either Adobe RGB or ProPhoto RGB. It has its own version of dust reduction rather than the digital ICE licensed by Nikon for their software, which may or may not make a difference.

Thoughts on these options?

[andrewrodney]

Originally Posted by stlsailor

The argument I've heard for doing it in Photoshop is that you have an unaltered archive image.

An ugly image that needs further fixing in Photoshop. But that assumes that some setting in the scanner is producing some kind of raw (not raw like DSLR linear capture) data. But who’s to know? Move the sliders and maybe you improve the preview and hence scanned data. Why not do that?

Its like the argument to always retouch on a layer. Makes sense because you have a back door. But clone dust spots on a layer? What’s the point of not burning the fix into the bkgnd? You can do either way, but I don’t see the point in having the full “before” ugliness unless you need to show someone at some point “look what I did for this fee, here’s the true before and after.”

Speed is probably the most significant issue. I think I'll run a test doing some of the adjustments in the software. What do you consider good software?

Good in general or good that will drive your scanner. My drum scanner had a fantastic produce called ColorQuartet. No way you’re using it on your Nikon. So probably SilverFast. Not pretty. Not really intuitive but lots of controls. I would do a test. Getting things fixed at the scan stage should be faster. You’re working with a low rez preview, not the full scanned data in Photoshop. But if Photoshop provides better controls, equaling a better appearing image, do it there.

Actually it doesn't look that good in sRGB or match the original slide very well. Also, according to the manual, scanner RGB doesn't embed a profile. Therefore, it sounds like it may be simply being tagged erroneously in EXIF data. Does that make sense?

Yes and that behavior is goofy.

• First, how to confirm if that's the case
• Second, assuming it is, what the optimal working space for it would be if there is one?

A device profile is used automatically by Nikon Scan 4, but if correct color space information is not passed, I don't know how that information can be used.

The preview you see in the scanning software UI should match what you see in Photoshop after the scan if color management is being properly used. The optimal space would be “myscannerRGB” as discussed. That you would archive if you wish. Then you convert into a well behaved RGB working space. I suspect that would either be Adobe RGB or ProPhotoRGB. One would have to plot the gamut of the “myscannerRGB” input profile beside Adobe RGB and see if its significantly larger, in which case you’d move up to ProPhoto RGB.

Fourth, it appears that VueScan is a reasonably priced program that will generate a device profile and use that to scan into either Adobe RGB or ProPhoto RGB. It has its own version of dust reduction rather than the digital ICE licensed by Nikon for their software, which may or may not make a difference.

Never used VueScan (I’m a Mac guy) so I have no comments.

[stlsailor]

An ugly image that needs further fixing in Photoshop...Move the sliders and maybe you improve the preview and hence scanned data.

Having looked at a number of unadjusted images now, I'm thinking you're right. Let the scanner do what work it can.

Given several thousand images to scan, I looked to see what automated setting would consistently give me an acceptable scan, leaving me free to edit further where I wanted. Here's what I found.

Digital Dynamic Exposure Extender (DEE) at a default setting to correct for underexposure in shadows and overexposure in highlights with its default setting, produced clearly better results about a third of the time. Sometimes it produced bad results.

Scan Image Enhance (SIE) to automatically adjust for contrast produced bad results about a third of the time, but sometimes produced the best results.

The combination of the two produced the best results or very close to it about a third of the time.

In each case I could make manual adjustments that looked better, but those manual adjustments would have been easier and faster in Photoshop.

That leaves me with no clear automated solution. I'm thinking to do an initial scan with DEE since it works best or close to it most often, then rescan with another option where the results don't look good. I don't want the work of multiple scans, but the only other option seems to be to do a RAW scan and edit in PS as time allows. It seems to be a trade-off between a non-optimal image and time. Life's like that.

So far as color spaces, scanning in scannerRGB (which seems to be incorrectly labeled in the EXIF as sRGB) and then converting to ProPhoto in PS gives fairly consistently good results. Given the cost of SilverFast I downloaded VueScan to take a look, but the trial version didn't have color management so I couldn't tell what it would do for me.

[kav]

I've tried prophoto for photos with a lot of saturation that I was trying to preserve, but it doesn't match up with a typical viewing setup. It's a D50 gamma 1.8 profile which isn't exactly comparable to modern display hardware. Were you looking at it because it was similar to the scanner's profile? Also does adobe 1998 show a lot of clipping when going from the scanner profile?

[kav]

I forgot to ask this stuff. Are you scanning negatives or film? Are you actually able to locate a scanner profile in your computer that matches up? Not something generic but one that was actually imported by the installation of your nikon scanner software. I see you saying convert to prophoto but there's no real data in the conversation of what it's tagged with before this, and no comparison as to if prophoto is a good match. Like are you importing it into an sRGB workspace without assigning a profile and then hitting convert or is it tagged with something accurate? Even if it is a good match, it still doesn't display that accurately, and it can produce some wacky results, not all of which you'll see on screen.

[stlsailor]

Are you scanning negatives or film?

For now Kodachrome and Ektachrome positives. Haven't started on the negatives yet.

Are you actually able to locate a scanner profile in your computer that matches up? Not something generic but one that was actually imported by the installation of your nikon scanner software.

The scanner hardware profile is loaded automatically in Nikon Scan 4. It's CMS allows you to select the color space for the image. The color space choices potentially appropriate for Windows are:

(1) Nikon Adobe RGB (1998) which is very close to Adobe RGB (1998) based on image and histogram comparisons though not exactly identical,

(2) Wide Gamut RGB which it says was designed by Adobe and is the same thing as Wide Gamut RGB was in Photoshop 5.0,

(3) Wide Gamut RGB compensated to allow it pick up more of what the scanner can scan in the blue area, and

(4) Scanner RGB which is primarily for use in Nikon Scan 4 and no ICC profile is passed to the host program.

It appears that for Scanner RGB no color space is embedded, but the EXIF data incorrectly shows it as sRGB.

I see you saying convert to prophoto but there's no real data in the conversation of what it's tagged with before this, and no comparison as to if prophoto is a good match. Like are you importing it into an sRGB workspace without assigning a profile and then hitting convert or is it tagged with something accurate?

So, when I convert to ProPhoto I'm scanning in Scanner RGB and then telling PS CS5 to convert it when I open the file. Whether it in fact is simply assigning it because there is no embedded profile, or whether it converts it based on an assumed sRGB profile I don't yet know.

Even if it is a good match, it still doesn't display that accurately, and it can produce some wacky results, not all of which you'll see on screen.

I'm not sure what you mean by this.

I did some comparisons of histograms from 3 images. I attached them to this message because seeing them is better than my trying to describe them. In every case, though, Adobe RGB had a slightly wider histogram which seems to say to me that NS4 was actually converting from what it thought was sRGB, not simply assigning the color space. I'd be interested in what conclusions you or others might draw from these histograms.

I've tried prophoto for photos with a lot of saturation that I was trying to preserve, but it doesn't match up with a typical viewing setup. It's a D50 gamma 1.8 profile which isn't exactly comparable to modern display hardware. Were you looking at it because it was similar to the scanner's profile?

I was looking at it because (a) it seemed like the most logical choice to match either the scanner's profile or Wide Gamut profiles, and (b) the books I bought when I upgraded to PS recently all recommended it (for 16-bit scans, not 8-bit). Up until now I've pretty much used Adobe RGB (1998).

Also does adobe 1998 show a lot of clipping when going from the scanner profile?

The histograms I uploaded may show more than I could explain in words.


Dale

[stlsailor]

Two additional pieces of information. First, I found some information that indicates in an earlier version of Photoshop that if the EXIF data indicated an sRGB color space, then that color space was used to try to convert it. I haven't been able to confirm that CS5 works the same way, but it's reasonable to suppose it does, especially since the narrower histograms seemed to suggest this.

Second, I tried saving a .nef file (which it turns out only seems to save in Adobe RGB) after finding out that PS would edit it. In the few instances I tried, it had better image quality than the TIFF files, and it opens in ACR. Note in one of these files I may have forgotten to reset the auto adjustments in ACR, though I don't think that made much difference.

A couple of updated histograms are attached.

Dale

[kav]

Once more, why prophoto? Your desire to use it suggests that you don't understand color gamuts because it doesn't map well to any device I can think of. Speculating on future devices is silly. If you want that, keep the scanner rgb because it's a better representation of your data in actual numbers. If you want to make adjustments in a space that actually can be viewed on a monitor with a reasonable degree of accuracy you probably want adobe 1998 but convert to srgb on a copy if you're posting it to the web or something for online viewing. Picking a non standard profile that doesn't match anything particularly well is pointless. If the point was just to have a really big color gamut we'd all work in LAB. It's also not so much a matter of "supported". You could still use colormatch rgb if you wanted to and photoshop would still recognize it, but it's not a good match to modern display hardware. A scanner profile actually embedded, meaning that it's tagged to the image would give you maximum color preservation with little to no correction made in the scanning software. It will just be annoying.

[andrewrodney]

Originally Posted by kav

Once more, why prophoto?

For raw workflows, its a no brainer, Adobe RGB is too small to contain the possible gamut of captures (note that the scene gamut as well as the so called capture gamut plays a role). For scanners, the native color space is an ideal archive space but not necessarily an editing space. It may not be well behaved where R=G=B is neutral. All synthetic RGB working space are wel behaved. If the gamut of the scanner color space is larger than Adobe RGB (1998), its not the editing working space space to be using, you’ll clip colors. ProPhoto will contain those colors just fine.

Your desire to use it suggests that you don't understand color gamuts because it doesn't map well to any device I can think of.

No working space necessarily does. To quote myself to save time, the old “round peg in square hole analogy is useful:

Gamut mismatch (fitting round pegs in square holes)

It IS true that the wider the granularity in a color space, the harder it is to handle subtle colors. This is why wide gamut displays that can't revert to sRGB (current LCD technology doesn't allow this.) are not ideal for all work (ideally you need two units).

There are way, way more colors that can be defined in something like ProPhoto RGB than you could possibly output, true. But we have to live with a disconnect between the simple shapes of RGB working space and the vastly more complex shapes of output color spaces to the point we're trying to fit round pegs in square holes. To do this, you need a much larger square hole. Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB again due to the simple size and to fit the round peg in the bigger square hole. Their shapes are simple and predictable. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance.

Speculating on future devices is silly.

NOT if you are facing the decision to throw away data and you don’t want to paint yourself into a corner.

If you want that, keep the scanner rgb because it's a better representation of your data in actual numbers.

True. It may not be the best editing color space. There is no reason not to archive the scanner data and move on assuming you don’t introduce any issues editing by the numbers (assuming neutrals are equal proportions of RGB). Otherwise, edit and archive in the scanner color space.

If you want to make adjustments in a space that actually can be viewed on a monitor with a reasonable degree of accuracy you probably want adobe 1998 but convert to srgb on a copy if you're posting it to the web or something for online viewing.

True. But again, if the data is wider in gamut than Adobe RGB (1998) and your output device is as well, do you clip colors so you can see them, temporarily on your wide gamut display, or use the colors on output and get a less than fully accurate representation of the data on the display? For most, they want the printer to be receiving as much data possible.

If the point was just to have a really big color gamut we'd all work in LAB. It's also not so much a matter of "supported".

Here we disagree. There are no Lab capture devices. You have to produce a conversion just to get into Lab, from in this case, scanner RGB. Might as well use it or ProPhoto. There are no Lab output devices, you have to convert again (although you would from an RGB working space). Lab has some real nasty behaviors that make it a poor editing space and while color described in Lab are more “real” than the two imagery primaries in ProPhoto (which fall outside of human gamut), users are going to be far better off in a wide gamut RGB space. Lab has a number of flaws that make it problematic Keep in mind that CIELab was just an attempt to create a perceptually uniform color space where equal steps correlated to equal color closeness based on the perception of a viewer. The CIE didn't claim it was prefect (cause its not). Most color scientists will point out that Lab exaggerates the distance in yellows and consequently underestimate the distances in blues. Lab assumes that hue and chroma can be treated separately. There's an issue where hue lines bend with increase in saturation perceived by viewers as an increase in both saturation and a change in hue when that's really not supposed to be happening. Further, according to Karl Lang, there is a bug in the definition of the Lab color space. If you are dealing with a very saturated blue that's outside the gamut of say a printer, when one uses a perceptual rendering intent, the CMM preserves the hue angle and reduces the saturation in an attempt to make a less saturated blue within this gamut. The result is mathematically the same hue as the original, but the results end up appearing purple to the viewer. This is unfortunately accentuated with blues, causing a shift towards magenta. Keep in mind that the Lab color model was invented way back in 1976, long before anyone had thoughts about digital color management.

[stlsailor]

For scanners, the native color space is an ideal archive space but not necessarily an editing space. It may not be well behaved where R=G=B is neutral. All synthetic RGB working space are wel behaved. If the gamut of the scanner color space is larger than Adobe RGB (1998), its not the editing working space space to be using, you’ll clip colors. ProPhoto will contain those colors just fine.

The two options which appear closes to the scanner color space are either Wide Gamut or Wide Gamut compensated. They are equivalent to Nikon AdobeWide RGB 4.0.0.3000 with one exception. The compensated one "redefines Wide Gamut RGB to include all the colors that can be output from the scanner. Because many of the colors that can not be expressed in Wide Gamut RGB occur in the blue portion of the gamut, the level of detail in the blue area has been greatly increased (because the gamut has been expanded in a nonlinear fashion to incorporate just those colors that could not otherwise be expressed, it can not be represented in chromaticity diagrams using a standard RGB triangle). As is the case with Wide Gamut RGB, most of the colors defined in this profile can not be reproduced on monitors and printers."

Question 1: Am I correct in thinking that (a) AdobeWide is the closest thing to the native color space of the scanner, and (b) that it's probably narrower than ProPhoto RGB?


When I open them in PS they open in ACR because they are .nef.

Question 2: The working options in ACR agive Adobe RGB and ProPhoto RGB but not Adobewide RGB. Therefore there seems to be no reason to use wide gamut RGB for a .nef file unless I decided to convert it into the wider ProPhoto space (which would not clip any scanner colors but will be wider than needed). Is this correct?

Dale

[andrewrodney]

Originally Posted by stlsailor

Question 1: Am I correct in thinking that (a) AdobeWide is the closest thing to the native color space of the scanner, and (b) that it's probably narrower than ProPhoto RGB?

I really have no idea. I don’t know what the scanner software is doing in the CMS path, that there indeed is “raw” RGB scanner data being provided to you, with the proper input profile (which ideally you’d make). The scanner is capable of producing what it produces, are you getting that out the software backend? That’s something Nikon would have to help you with.

[kav]

Originally Posted by andrewrodney

I really have no idea. I don’t know what the scanner software is doing in the CMS path, that there indeed is “raw” RGB scanner data being provided to you, with the proper input profile (which ideally you’d make). The scanner is capable of producing what it produces, are you getting that out the software backend? That’s something Nikon would have to help you with.

I think you're misinterpreting what I was getting at slightly. We weren't talking about exporting with prophoto but rather converting to it after. If you bring up prophoto in any color management software you'll see that while it is large, it does clip vs. some spaces in certain areas when mapped against them too, and aside from that doesn't display that well on screen. Just by what it includes and what it doesn't I never found the space to be ideal for anything. I was suggesting if you're outputting (from the scanner software) in a wider gamut such as the scanner profile archiving in that if you're not going to use a working profile for final saves. Also just to clarify Adobe RGB is a little different. I suggested Adobe 1998. I have them as 2 different profiles. I'm going to see if google can help me find info on the settings/hardware profile of that machine.

[andrewrodney]

The best, purest data is the scanner RGB data defined by a profile which can then be converted into ProPhoto or Adobe RGB or whatever. Its totally unclear with the conversion path is for this software driver. For all we know, the conversion is Native RGB (which you can’t get ahold of) to some other RGB color space to ProPhoto. We don’t know the engine (CMM). It would be a lot more useful to get scanner RGB with a custom input profile, then worry about what RGB working space you’ll convert to later in Photoshop (where you have full control).

[kav]

Originally Posted by andrewrodney

The best, purest data is the scanner RGB data defined by a profile which can then be converted into ProPhoto or Adobe RGB or whatever. Its totally unclear with the conversion path is for this software driver. For all we know, the conversion is Native RGB (which you can’t get ahold of) to some other RGB color space to ProPhoto. We don’t know the engine (CMM). It would be a lot more useful to get scanner RGB with a custom input profile, then worry about what RGB working space you’ll convert to later in Photoshop (where you have full control).

I hadn't thought of that, but you could be right. Could also be something like input profile --> LAB ---> Adobe/prophoto/etc.

Regarding custom input profiles, don't they ship IT8 targets with that model?