LS4000 14 bit per color HDR?

[rlk]

I have recently downloaded the Nikon LS4000ED demo version of Ai. If I use it to do a 48 bit HDR scan with gamma disabled, and examine the resulting tiff image in Matlab (Photoshop being useless for detailed analysis of images), it is clear that Ai is not saving 14 bit linear data from the scanner. Using v**s**n, I have confirmed that indeed the scanner does provide true 14 bit data, so the question is how do I get it from Ai?

[LSI_Flyvbjerg]

Dear rlk.

Scanning 14 bit HDR in SilverFast means that the raw data from the scanner are moved 2 bit up to make 16 bits values. The least signficant two bits (bit 0 and 1) are invalid (or zero).

Eric.

[rlk]

That is what it should be, but it is in fact not. The simple way to see there is a problem is to bitwise AND the data with 3. The result should be all 0 but it's not. The second way to see there is a problem is to do a 2^16 bin histogram. You will find the pixel values near 0 are spaced by 16 not 4.
Raw data from v**s**n passes both these tests.

[degrub]

What result are you getting from NikonScan ? Perhaps this explains the low cutoff in the dark areas of slides that NikonScan is famous for. If so maybe it is a problem in the Nikon Maid module (v**s**n does not use it, so i am told)

Frank

[rlk]

Nikon Scan also has a problem, which is similar, but not necessarily identical. I have an inquiry into Nikon about that, but it is presently unresolved. I may actually be able to figure out the shape of the transfer curve by scanning the same slide with v**s**n, NikonScan and SilverFast and using the v**s**n raw data as the reference. The SilverFast result will be perturbed by the watermark from the demo version, but it may not matter.

[rlk]

I have been doing some additional scrutiny of raw files produced by v**s**n. If the raw files produced by v**s**n truely represent the data produced by the scanner, then Nikon is to some extent pulling a fast one when advertising a 14 bit A/D. One would expect a scan of a full range transparency to 2^14 (16384) distinct values (for each color). In fact, I am getting less than 4096 (2^12). One can deduce the transfer curve from the histogram, and it is apparent that for approximately the range 0 to 1000, the pixels are spaced by 4 consistent with 14 bit, then from 1000 to 2000 they are spaced by 8, which is consistent with 13 bit, then 16 consistent with 12 bit. In short, it seems to be 14 bit data encoded in 12 bits. I am guessing Nikon did this to make the LS4000 data consistent with the LS2000 everywhere except in the deepest shadows. Statistically, this is not necessarily a bad thing since the LSBs become progressively less relevant as the brightness increases, but it is important for anyone using the data from the scanner to know what is going on. And to advertise a 14 bit A/D without delivering them all seems questionable (it would be appropriate to claim 14 bit dynamic range with 4096 levels).
If anyone has mangaged to actually get 14 bit data out of this scanner, I would be very interested to know how they did it.

[rlk]

It appears that Nikon does deliver the full 14 bits advertised. Using Nikon Scan, with ICM off, and Digital ICE off, scaning at 4000 dpi, 1x sampling, the image histogram shows the expected number of levels, with the expected spacing, indicating a full 14 bit resolution. Furthermore, if one drops to 1000 dpi, you get 16 bit data, so the scanner is actually properly averaging.
However, if you turn on Digital ICE, you get only 12 bit resolution and, surprisingly, the 16x histogram also shows only 12 bits, so it appears that there is a distinct price to be paid for getting rid of dust and scratches.
This also suggests that the raw scans produced by v**s**n (see previous in thread) are not that raw.

[degrub]

It would be interesting to ask ASF about the loss of data bits, since they are using a separate channel through the same A/D chip. i may post a note on high end scanner group, as their president routinely reads the group. Good to hear Nikon "raw" is just that. Curious though, as to why the bit depth increased when the resolution decreased. It would seem that should not change as the bit depth of the A/D is fixed. i understand why the apparent bit depth is increased with multisampling, but not with resolution changes.

Frank

[rlk]

The reason for more bits with decreased resolution is because it is a form of multi sampling. The scanner has an intrinsic resolution of 4000 dpi. If you scan at 1000 dpi, each pixel contains 4x4 or 16 scanner pixels. These are averaged to form the data returned. This averaging effectively gives you more bits.

[Caleb Clapp]

This is a most interesting post!

I need to scan/archive 5,000 color negatives on a 4000 ED. I had intended to use AI set to RAW 48bit HDR output, and process post scan in HDR with Job Manager. I had been thinking I might get a more "true" RAW scan by using Nikon's native NEF raw format through Nikon Scan software, compared to HDR. This thread seems to support that idea. The problem is, I do not believe HDR can read 48bit NEF files. I have heard that SF DCPro WILL support 48bit NEF files.

That being the case, would you think RAW NEF scans for processing in DCPro would be the most "true" workflow?

If I am wrong, and DCPro will not read NEF files, I have three choices given the large number of negatives:
1) AI set to 48bit HDR output>HDR with Job Manager
2) Nikon Scan 48bit TIFF>HDR with JobManager
3) ViewScan RAW TIFF>HDR with JobManager (assuming these are compatible)

Which, sounds like the best choice? Are there other options?

Thanks

--Caleb

[LSI_Flyvbjerg]

Dear Caleb.

The NEF format is designed for Nikons digital cameras. HDR can?t read NEF, but DCPro can. The normal 48-bit from the scanner do contain all data you need for post processing.

You can use either Ai, NikonScan or v**s**n. It? s simple a question, which software you like best. Of course we would recommend Ai and then use HDR with JobManager for post processing.

Eric.

[Caleb Clapp]

Dear Caleb.

The NEF format is designed for Nikons digital cameras. HDR can?t read NEF, but DCPro can. The normal 48-bit from the scanner do contain all data you need for post processing.

You can use AI, NikonScan or v**s**n. It? s simple a question, which software you like best. Of course we would recommend Ai and then use HDR with JobManager for post processing.

Eric.

Thanks Eric!

Is there any reason I should expect any mis-match of colors/settings/etc resulting from raw 48bit negative scans in NikonScan NEF or v**s**n raw, when these files are subsequently processed in SF HDR/DCPro?

I realize people say there are differences in the levels/colors/etc between scans form each of the three programs. My question is not to say will differences exits in the RAW scans, but rather if these scans are later processed in HDR/DCPro, will there be NEW/ADDITIONAL problems/issues introduced because the program performing the processing IS NOT the same as the program used in making the raw scan?

I hope this question is clear

If there will be mis-match problems, would you please state why?

Thanks a lot!

--Caleb

[LSI_Flyvbjerg]

Dear Caleb.

For SilverFast it doesn?t matter, which application made the raw scans. I would expect all 3 apps to generate the same raw files.

Eric.