Seeking to digitize medium format with VueScan

Don, what's wrong with 'gamma 1.0' and 16 bit files is that it doesn't necessarily mean you're preserving the most tonal quality from your negatives.

...

Unfortunately, from your sample, it appears that Vuescan saves its 'raw' files in a bottom-up, dark and dingy, fashion, rather than top-down.

 

So, if possible you should increase the brightness of those 'raw' scans as much as possible for archival use. Otherwise any advantage of a 16 bit file depth is just wasted.

 

FWIW, it would make far more efficient use of file space, and give better tonal quality, if a log-law 'gamma' was applied in analogue form before the A/D stage of any scanner/digital camera. But that would be too much to hope for!

 

Yes, the sample is dark and dingy, in fact much of the roll is that way and I am not sure why, but underexposure seems part of the issue. The conditions: a massive thunderstorm was approaching in late afternoon. Normally the scans are not dark and dingy.

 

Same roll

 

 

Yes, the sample is dark and dingy, in fact much of the roll is that way and I am not sure why, but underexposure seems part of the issue.

Under Exposure of the neg?

Under Exposure of the neg?

 

I thought there might be a chance of that on that roll due to the shooting conditions. After some testing, I think the 'dark and dingy' scans are due to the "output color space" being set to something other than "Device RGB", probably Prophoto which I use for some scanning. So, operator error. Rescanning the first example above this morning with output set to Device RGB resulted in a scan similar looking to the 2nd example. After converting both to positive, the results do not differ. I made raw scans with the settings Color Negative, Image, and Slide, then also scanned with the "Save With Film" set. The look of the scans may be different, but conversions of them with Color Perfect are very similar.

Indeed, IF it is a linear scan but assigned anything but the profile defining this, it will appear too dark.

A typical colour negative has a density range of under 3.0D across all dye layers.

Profoto 100 curves:

While a properly exposed and developed B&W neg tops out at around 2.4D.

 

These represent brightness ranges ('dynamic ranges') of about 1000:1 and 250:1, respectively, and translate to bit-depths of only 10 and 8 bits in linear space.

 

However, using only that bare minimum of bits would, as previously explained, result in severe posterisation of the lowest brightness values. Therefore those values need to be elevated to occupy the higher bit values of a greater bit-depth digitisation.

 

It matters not whether this is done through increased physical scanner exposure, or by adding an artificial voltage offset to the A/D converter input. All that matters is that the digital values are 'shoved' up to the top end of the 16 bit container file.

 

A dark appearance of the raw file shows that this isn't being done, and that therefore some refinement of tonal discrimination is being lost.

 

The example showing the dark rooves being almost transparent in the negative is much closer to ideal.

Edited February 13, 2021 by rodeo_joe|1

Got a screen capture? I'm not understanding how you can go 'past the ends' of a Histogram.

 

IF done in high bit, that's OK assuming you didn't clip the range doing step one above which needs further clarity.

 

It's not the scanner, it's what drives the scanner; the software.

Is there a difference? Well you have the scanner, the scanner driver and the film. Why not scan both ways and upload (or better, examine the two themselves). You're asking a question best answered by actually taking some time to do a test. Or at least make two scans and allow others to assist you in analysis. Anything else is, like your assumption, another assumption.

To be clearer, by histogram ends, I mean the end of what the picture is giving in the histogram, not past the 0 and 255. So if the range of the picture was, for example, 15-200 on the pre-scan, I'd set the black and white points at around 10-210. I have compared the result of doing it that way against scanning 0-255 and then adjusting levels afterwards in post. I really couldn't tell the difference and the file sizes were about the same. But some other people told me I was mistaken. That selecting the points before the scan provided better data (quantity?) to work with. But, I never was able to get to the bottom of what is actually the better method.

To be clearer, by histogram ends, I mean the end of what the picture is giving in the histogram, not past the 0 and 255.

Not clear, but if and when you show us the Histogram and the scanned data, in a screen capture, better.

 

In the meantime:

Everything you thought you wanted to know about Histograms

What are histograms. In Photoshop, ACR, Lightroom.

Histograms: clipping color and tones, color spaces and color gamut.

Histogram and Photoshop’s Level’s command.

Histograms don’t tell us our images are good (examples).

Misconceptions about histograms. How they lie.

Histograms and Expose To The Right (ETTR).

Are histograms useful and if so, how?

Low rez (YouTube):

High rez: http://digitaldog.net/files/Histogram_Video.mov

 

I have compared the result of doing it that way against scanning 0-255 and then adjusting levels afterwards in post. I really couldn't tell the difference and the file sizes were about the same.

You compared how, using what? You know how to subtract two images in Photoshop to view differences, and then how to evaluate what the differences mean, if they exist???

Of course the file size is the same. There is no reason it shouldn't be.

But some other people told me I was mistaken.

The less said about that, the better.... :D

Edited February 13, 2021 by digitaldog

A dark appearance of the raw file shows that this isn't being done, and that therefore some refinement of tonal discrimination is being lost.

Or, the dark appearance is due to a misunderstanding of the scale of the numbers due to an incorrect ICC profile defining said numbers. We've been there, there are actual examples that show how an image with ideal brightness values of the RGB numbers, appear dark due to the scale of those numbers being misinterpreted.

Or, the dark appearance is due to a misunderstanding of the scale of the numbers due to an incorrect ICC profile defining said numbers.

Yes, an ICC profile can tell a monitor how bright to render a particular digital number. What it can't do is put back the numbers between tones that were never captured in the file to begin with.

 

A profile is just a look-up table. It has nothing to do with the original capturing hardware or linear data file, which needs to be set up properly to capture the most tonal refinement.

Yes, an ICC profile can tell a monitor how bright to render a particular digital number.

The display profile can provide information about how 'bright" and more, a display behaves. By itself, one had clapping. No color managed preview exists without another profile; the scale of the numbers in the document. In a Linear encoded document (or not). The two are used with Display Using Monitor Compensation to produce that preview. IF the linear image has no profile and is assumed otherwise, the preview is wrong; it looks too dark. Assign a linear profile to data that isn't linear, the opposite takes place; the image previews too bright.

 

The point is, in both cases, the preview is WRONG. The data isn't too dark or too light. Your being lied to, akin to taking an image that isn't too dark or bright and altering the controls on your display to max brightness or the opposite. Don't do that.

What it can't do is put back the numbers between tones that were never captured in the file to begin with.

And AFAIK, no one has suggested otherwise. If you are viewing numbers incorrectly, if you assume they are incorrect, or you edit those numbers based on an incorrect preview, you fail.

A profile is just a look-up table. It has nothing to do with the original capturing hardware or linear data file, which needs to be set up properly to capture the most tonal refinement.

And AFAIK, no one has suggested otherwise so I'm not sure why you're going into such rabbit holes.

The data is the data; the profile defines the scale of the numbers so, along with a display profile of the state of the display, the numbers are correctly shown to you.

Linear data or gamma corrected values may be too dark or too light or not appear gray balanced when RGB values do define a gray. How do you view the numbers so they appear to correctly represent the data? With both an ICC profile defining the data and the display.

Are all linear encoded scans or images too dark? No. Can they be too dark? Yes; and we define this visually on screen with color management using a display profile and a profile of those linear values. Can a linear encoded image appear too dark when the image data isn't? Yes. When the profile defining that data isn't correct. Don't do that.

Edited February 15, 2021 by digitaldog

I'm looking to digitize 14 medium format negatives. I have been using VueScan myself with a Coolscan IV to digitize every 35mm, 110, Instamatic negative and slide I can get my hands on. Unfortunately the Coolscan IV is too small for medium-format and the results with my flatbed scanner are absolutely inadequate.

 

I could certainly go to a local lab and have them digitized, but I really want to receive back VueScan raw files.

 

Is anyone familiar with a processor that digitizes negatives commercially using VueScan? Alternately, where a guy could rent a suitable scanner to be used in Minnesota?

 

I'm back home with my scanner sooner than expected. If you'd like to send the MF frames to me for scanning, get in touch here.

so I'm not sure why you're going into such rabbit holes.

The 'rabbit hole' is discussing profiles when there was no previous mention of them.

 

The raw file and linear-space issue is: What can be done at the scanning stage to ensure that the most information is obtained from the negative or slide?

 

After digitisation, that train has already left the station, and no profile can do anything to alter a lack of tonal refinement already embedded in the digital file.

 

Let's take 3 simple examples of linear digital representation:

A) A 10:1 brightness range in the film can be represented by the numbers 1 to 10

B) The same brightness range can be represented by the numbers 100 to 1000

C) The numbers 6000 to 60,000 can also represent a 10:1 brightness range.

 

In case (A) only 10 discrete levels of brightness can be represented.

In case (B) 900 discrete levels of brightness can be represented

In case © 54,000 discrete levels of brightness can be represented.

 

All of the above numbers can be held in a 16 bit digital word. So, in which set of numbers should we aim to hold the digital representation of our 10:1 brightness range?

 

At the low (dark) end of the digital file? Or at the highest (brightest) end of the file?

 

This decision - really a no-brainer - has to be taken at the scanning stage, and before or during digitisation; by adjusting the scanning exposure, or via the scanning software, which can (hopefully) program the analogue gain and offset of the A/D converter.

 

All of which has absolutely nothing to do with colour profiles.

Edited February 17, 2021 by rodeo_joe|1

The 'rabbit hole' is discussing profiles when there was no previous mention of them.

Until necessary, a post you must have missed:

According to the User Guide "The image gamma value is 1.0 when there are two bytes (16-bits) per sample...Raw files saved with gamma 1.0 will look dark, but this is normal."

It isn't normal, all one needs is to view the linear image correctly, with the correct ICC profile.

After digitisation, that train has already left the station, and no profile can do anything to alter a lack of tonal refinement already embedded in the digital file.

Yes, you wrote that once before and I had to remind you then, and once again, no one said otherwise. And that has zero to do with: "Raw files saved with gamma 1.0 will look dark, but this is normal."

An example of a linear capture with its profile was provided as proof of concept. Proof you never examined it seems. All of which has absolutely everything to do with "colour" profiles.