Silverfast 8: 16bit grey scale?

Unaltered Vuescan generated raw files. 16 bit capture, save 16 bit raw, 16 bit capture, save 8 bit raw, 8 bit capture, save 8 bit raw. The file names match what was done.

http://m.avcdn.com/sfl/vuescan_raw_8_bit_16_bit_comparison.zip

The same basic analysis as before;

raw-acquire-16-bit-save-16-bit-raw.tif
sensor resolution: 9064x6046 px
bits per sample: 16 bits
analyze window_size: +-1024, x1: 3508, x2: 5556, y1: 1999, y2: 4047
max_r:1945, max_g:2115, max_b:1791
min_r:0, min_g:0, min_b:0
avg_r:517, avg_g:440, avg_b:402

raw-acquire-16-bit-save-08-bit-raw.tif
sensor resolution: 9064x6046 px
bits per sample: 16 bits
analyze window_size: +-1024, x1: 3508, x2: 5556, y1: 1999, y2: 4047
max_r:59904, max_g:59624, max_b:18724
min_r:0, min_g:0, min_b:0
avg_r:5011, avg_g:5138, avg_b:4875

raw-acquire-08-bit-save-08-bit-raw.tif
sensor resolution: 9064x6046 px
bits per sample: 16 bits
analyze window_size: +-1024, x1: 3508, x2: 5556, y1: 1999, y2: 4047
max_r:14906, max_g:48512, max_b:32639
min_r:0, min_g:0, min_b:0
avg_r:2009, avg_g:1943, avg_b:1854

All three files have different results, so Vuescan does treat 8 bit raw files differently depending in the bit rate it was captured at.

Furthermore, just for transparency, here is the full email exchange in my questioning Vuescan's behavior. Private information has been redacted.

____
From: Ed Hamrick
Date: March 27, 2022 at 12:01:28 PM PDT
To: Adrian Bacon
Subject: RE: VueScan Problem Report from xxxxx@xxxxx.com


When saved at 8 bits per sample, it’s saved with a gamma 2.2 lookup table.

Regards,
Ed Hamrick

From: Adrian Bacon
Sent: Sunday, March 27, 2022 2:42 PM
To: Ed Hamrick
Subject: Re: VueScan Problem Report from xxxxx@xxxxx.com

Thank you. If I may, a follow up question: if I acquire in 16 bits and save as 8 bit raw, is it a straight scaling to 8 bits?

On Mar 27, 2022, at 11:25 AM, Ed Hamrick wrote:


The raw files don’t have any gamma applied.

Regards,
Ed Hamrick

From: VueScan Problem Report
Sent: Saturday, March 26, 2022 9:34 PM
To: xxxxx@xxxxx.com
Subject: VueScan Problem Report from xxxxx@xxxxx.com

Email: xxxxx@xxxxx.com
Country: US
Category: question
Model:
OS: Mac OS X 10.15.7
Browser: Safari 14.1.2
Problem:
SerialNumber=xxxxxxxxxx
CustomerNumber=xxxxxxxxx

I'm doing some work to characterize the ADC noise performance of an Epson v850Pro and was wondering: if I acquire at 16 bits and save raw in 16 bits is there any gamma applied? If I acquire in 8 bits and save raw in 8 bits, is there any gamma applied? Is the behavior the same between color and monochrome capture? Thank you.
____

I have nothing more to say and paid work to get to.

Alan Edward Klein said:

Here's the first flat (raw) scan adjusted in Photoshop Elements 2020. The only setting was Levels Auto. What's interesting and unrelated to this discussion is that Elements corrected the colors. I could not do that in Lightroom or manually in Elements using manual Levels. Auto levels works great. MAybe a should try negative film again. Elements seems to handle it well. I'm going to have to try Aiuto adjustments in Epsonscan again to see if that corrects too. Of course, Kodak says Portra is good for scanning.

View attachment 301722

Click to expand...

Looks like a good find for a nice workflow for you.

Here are four files scanned on the Epson V750. The first was saved as a 16 bit TIFF (16 in 16 out). The second was taken from the very same scan saved as a 16 bit RAW (16 in 16 out). The third (16 in 8 out) was stored as RAW from the very same scan . The forth was RAW taken from the second scan (8 in 8 out.). For the record, a TIFF file from the second scan looked like the 16 bit TIFF from the first scan and the 8 bit RAW from the second scan. I am not uploading that one because it provides no additional useful information. Note. The files uploaded are jpeg version from the original TIFF and RAW files.










The ONLY consistent explanation for the fact that the 16 bit RAW image looks different from all of the other images and that both of the 8 bit RAW images look very much like the 16 bit TIFF image is that all of the images except for the 16 bit raw were gamma encoded. That includes both 8 bit RAW files, regardless of whether they started out as 16 bit or 8 bit input. This is pretty definitive proof that 16 in 8 out RAW files are gamma encoded, no matter what Mr. Hamrick said in his communications with Adrian. Please note that Mr. Hamrick brushed Adrian off rather than giving a meaningful response to his request for final clarification.

8 bit RAW files are gamma encoded and can't be directly compared to 16 bit raw files.

I would be happy to post images of the histograms from the original TIFF and RAW files if requested, but visual inspection should be sufficient to demonstrate the point.

alanrockwood said:

Here are four files scanned on the Epson V750. The first was saved as a 16 bit TIFF (16 in 16 out). The second was taken from the very same scan saved as a 16 bit RAW (16 in 16 out). The third (16 in 8 out) was stored as RAW from the very same scan . The forth was RAW taken from the second scan (8 in 8 out.). For the record, a TIFF file from the second scan looked like the 16 bit TIFF from the first scan and the 8 bit RAW from the second scan. I am not uploading that one because it provides no additional useful information. Note. The files uploaded are jpeg version from the original TIFF and RAW files.

View attachment 301780

View attachment 301781

View attachment 301782

View attachment 301783


The ONLY consistent explanation for the fact that the 16 bit RAW image looks different from all of the other images and that both of the 8 bit RAW images look very much like the 16 bit TIFF image is that all of the images except for the 16 bit raw were gamma encoded. That includes both 8 bit RAW files, regardless of whether they started out as 16 bit or 8 bit input. This is pretty definitive proof that 16 in 8 out RAW files are gamma encoded, no matter what Mr. Hamrick said in his communications with Adrian. Please note that Mr. Hamrick brushed Adrian off rather than giving a meaningful response to his request for final clarification.

8 bit RAW files are gamma encoded and can't be directly compared to 16 bit raw files.

I would be happy to post images of the histograms from the original TIFF and RAW files if requested, but visual inspection should be sufficient to demonstrate the point.

Click to expand...

what does it do if you perform a separate scan for each combination? I performed a separate scan for each combination on my last post, and it clearly has different results for each. Myself being a software person that has a fair amount of experience writing software, I doubt vuescan has a full input/output matrix coded up to handle every single combination of input and output the way we think it should, especially if multiple outputs, or outputs generated from previous scans are selected, and it instead defaults to some baseline in those instances, so you might not actually be getting what you think you should be getting unless you actually perform a scan with just the settings you want for one output.

might be worth doing some troubleshooting on your end to see what it does. If you don’t, at some point, when I get the time I will, however I do actually have a business to run with paid work to do, and spending time here doesn’t pay the bills.

Adrian Bacon said:

what does it do if you perform a separate scan for each combination? I performed a separate scan for each combination on my last post, and it clearly has different results for each. Myself being a software person that has a fair amount of experience writing software, I doubt vuescan has a full input/output matrix coded up to handle every single combination of input and output the way we think it should, especially if multiple outputs, or outputs generated from previous scans are selected, and it instead defaults to some baseline in those instances, so you might not actually be getting what you think you should be getting unless you actually perform a scan with just the settings you want for one output.

might be worth doing some troubleshooting on your end to see what it does. If you don’t, at some point, when I get the time I will, however I do actually have a business to run with paid work to do, and spending time here doesn’t pay the bills.

Click to expand...

I believe you are right that vuescan doesn't have code to handle every combination of input and output. My guess (and it's just a guess) is that when it comes to gamma encoding for 8 bit raw scans he probably only has one method. (By the way, I'm sure you know that I am using the term "encoding" in correctly. That's not actually the correct technical term for the gamma transformation, but I guess I use it because it is more intuitive and descriptive to me.)

A very good reason for having only one gamma transformation method when doing 8 bit raw scans is that he has to read them back into vuescan for further processing, which would be a nightmare if he were to have more than one scheme for gamma encoding in that part of the progam. Then there is the question that you raised of why is Hamrick even doing gamma coding for 8 bit "Raw" scans. It seems to me that there is nothing to gain from it, and it kind of goes against the philosophy of raw scans.

If he is doing a gamma encoding according to the sRGB standard then it's not actually a simple power law over the whole range, but a linear portion at low signal levels grafted into a non-linear function at higher signal levels. This would be consistent with the fact that when one zooms in on the histogram horizontal scale the first few peaks are evenly spaced, which would not be the case if the transformation were a true power law relationship. If I were to hazard a guess it would be that he is using the sRGB standard to do the gamma encoding when it comes to applying it to 8 bit "raw" scans. If he is following that standard then reversing the process would be relatively simple for the low signal levels (which is the relevant range when dealing with inherent noise in the instrument) because it's just a linear transformation.

When are we going to get to the part about whether it is better to do 8 bit scans (8 bit scan/8 bit save) or 16 bit scans (16 bit scan 16 bit save)? When you do so, please give us you definition of "better" so we know that everyone is on the same page. Thanks.

faberryman said:

When are we going to get to the part about whether it is better to do 8 bit scans (8 bit scan/8 bit save) or 16 bit scans (16 bit scan 16 bit save)? When you do so, please give us you definition of "better" so we know that everyone is on the same page. Thanks.

Click to expand...

From the limited testing I've done, acquiring at 16 bits is definitely less noise and more dynamic range than acquiring at 8 bits, at least on the Epson v850, so the question really is whether or not saving at 16 bits or 8 bits from a 16 bit acquisition is worth it. For black and white, gamma encoded 8 bit is most likely fine for most uses except maybe the most extreme tone curve adjustments, but I'd still recommend 16 bit saves if doing color work as the per-channel adjustments to get the color right will often be quite extreme and having more discrete tone values is helpful simply because hue "tearing" and discontinuous hue and saturation shifts tend to crop up a lot earlier than other types of artifacts when you don't have enough discrete tone values and don't look very attractive. With black and white, you only have to worry about luminance smoothness (or perceived smoothness), but with color, you have to worry about that along with smoothness in hue shifts, AND smoothness in saturation shifts. This also depends on your application. If you're just scanning in images on paper, you probably don't need to worry about that, but if you're digitizing color negative film, you'll run into that really fast if you're only saving 8 bits unless you do all that work in the scanner software before it's saved.

So, long story short, there's no simple answer, it depends on what you're doing.

Adrian Bacon said:

So, long story short, there's no simple answer, it depends on what you're doing.

Click to expand...

Thank you. The decision looks pretty straightforward to me.

Given the thrust of Alan Rockwood's comments, I gather he might not agree with you in all respects, but I will await his further comments before drawing any firm conclusions about where he stands on the issue.

faberryman said:

When are we going to get to the part about whether it is better to do 8 bit scans (8 bit scan/8 bit save) or 16 bit scans (16 bit scan 16 bit save)? When you do so, please give us you definition of "better" so we know that everyone is on the same page. Thanks.

Click to expand...

Like so many things in life there's probably not a simple answer to the question "When?'.

The shortest possible answer is that In theory it is always better to scan in 16 bit mode, but the question is whether it makes a practical difference. If one can't tell the difference between 8 bit and 16 bit mode in terms of dynamic range and banding then 8 bit scans are good enough, and it's not worth using the extra disk space to do 16 bit scans. If you can tell the difference between 8 bit mode and 16 bit mode then it's better to scan in 16 bit mode. Think of it in terms of an analogy to money. Is it going to make practical difference in my life if my net worth is $1,000,000 vs. $999,999? If I were in that situation then the $1 difference would not be worth worrying about. But if the difference were between $500,000 vs. $1,000,000 then it would be worth worrying about. For some people even a $1 difference might be worth worrying about.

Drilling down into this in a little more detail, one can think of the problem in terms of the following two stages. I'd say that this discussion is currently in stage #1, which basically comes down to how noisy is the scanner itself.

1) Is there inherent noise of the scanner itself is so high that it is detectable when scanning in 8 bit mode? This might depend on which scanner is used because some scanners are noisier than others. If the scanner is this noisy then it won't make a practical difference whether one scans in 8 bit or 16 bit mode, In that case 16 bit scans are not justifiable on a technical level, and using a finer grained film won't help. However, 16 bit scans might be justifiable on a psychological level for some people.

2) If the scanner passes the noise floor test (i.e. is the noise so low that it doesn't show up in 8 bit scans) then the question becomes "Can I see film grain in my scans?" If grain is present in 8 bit scans then it doesn't really matter if you scan in 8 bit or 16 bit mode. If scans can be grainless (as in "virtually undetectable under close scrutiny") when scanning your most grain-free film then scans for that type of film should be done in 16 bit mode. If grain is visible in even the most grainless type of film you use then 8 bits is good enough for any type of film you use when considered on a technical level, but 16 bit scans might be justifiable on a psychological level. (By the way, one could simply bypass test #1 and just go directly to test #2.)

If you don't want to go to the trouble of characterizing the noise level of your scanner and/or the amount of grain in the film(s) you use then the safest bet is to just scan in 16 bit mode and don't give it another thought. That's if you have a scanner/software combination that can scan in 16 bit mode. Most can, but some can't. If the scanner/software combination you use can't do 16 bits then the tests outlined above will tell you if it matters. If it doesn't matter based on these tests outlined above then just use the scanner and don't worry about it.

Personally, I have never produced a grain-free scan of a negative film, so 16 bit scans are not justifiable from a technical stand point in my situation. I haven't scanned enough slides to answer the question for slide films. This may be different for other people using different scanners and films.

faberryman said:

Thank you. The decision looks pretty straightforward to me.

Given the thrust of Alan Rockwood's comments, I gather he might not agree with you in all respects, but I will await his further comments before drawing any firm conclusions about where he stands on the issue.

Click to expand...

Well, I suspect that some of his conclusions where drawn on results he was getting with Vuescan where he might not have been getting what he thought he was getting due to his particular workflow and what I strongly suspect is Vuescan's input/output matrix handling. There's nothing invalid with that, but it is important to make sure we're aware of and/or disclosing key technical details to reduce confusion as much as possible. It's also OK if he and I don't agree. The only person who can decide what is best for you, is you. This is why I make my files available for download. So people can draw their own conclusions and decide what is best for them. If you or Alan decide what's best for each of you is different than what I think is best for me, that's totally fine. Anybody can make recommendations, but at the end of the day, what you decide for yourself is your deal, and that's totally OK.

It looks like several posts have occurred while was preparing my last post.

Addressing the point of noise in 16 bit vs. 8 bit noise levels. If the electronics and digital programming of a scanner are designed correctly then if noise shows up at 8 bit scanning then it will show up at essentially the same relative level at 16 bits. For example, if noise were 1% of full scale in an 8 bit scan it will also be at 1% of a 16 bit scan. The only difference would come in because of round-off error and digitization error, which are closely related to each other, and this can show up noticeably when the root mean square noise level is less than about one ADC step size of the 8 bit digitzer. As the noise level gets lower the first noticeable change will be dynamic range, and the next noticeable change will be that banding can become visible under extreme image manipulation.

In comparing the inherent noise level of 8 bit vs. 16 bit scans it is necessary to do the comparison under comparable conditions. Most importantly, one can't compare 8 bit scan that has undergone gamma transformation with a 16 bit scan that has not undergone gamma transformation. The underlying reason for this is that the gamma transformation spreads out the data in the low range, making the data look "wider" in that range, so noise levels that would be similar if histograms (or the images themselves) are both viewed in linear signal space do not look similar if one of the scans has undergone gamma transformation.

I'm going to do a little math to show what I mean. I'm going to use a simple gamma transformation equation for illustration purposes. Real gamma transformations typically are not quite that simple, but the principle being illustrated is the same. consider an image of a dark region whose histogram were to consist of three peaks in linear signal space, one at 0% of full scale, one at 1% of full scale and one at 2% of full scale. Let full scale have a value of 1. Consider a gamma transformation with a gamma equal to 2, and assume that the following equation governs the transformation.

output = (full scale)*(input)^(1/gamma)/(full scale)^(1/gamma)

This equation is a power law that preserves the zero point and the full scale point. If full scale is 1 gamma is 2 then the equation reduces to the following form

output = input^(1/2)

The (input, output) list for 0%, 1%, and 2% fill scale looks like this.

(0, 0)
(0.01, 0.1)
(0.2, 0.141)

As you can see, after gamma transformation the fist peak beyond the zero peak is at 10% full scale instead of 1% full scale, and the second peak is at 14.1% full scale instead of 2% full scale. Thus, the noise spectrum after gamma transformation looks like its far worse, even though it's not. The apparent spreading of the noise is a mathematical artifact of the gamma transformation, not a result of a difference in noise level itself.

Therefore, if one were to compare noise in the low-noise region for two scans that have the same relative amounts of noise (relative to full scale) of one of the scans had undergone gamma transformation it would look far nosier than the other, even though it is not actually noisier.

This is why you can't compare the low-level noise of an image that has been gamma transformed from one that has not.

To date in this discussion there has not been a comparison of a linear 16 bit results to a linear 8 bit result. There has only been a comparison of a linear 16 bit result to a gamma transformed 8 bit result, And this is why a proper comparison has not yet been done.

I mentioned already that real gamma transformation processes don't necessarily follow a simple power law, but the spreading of the signal at low signal levels is still a feature of the gamma transformation process, even for those that use more complicated algorithms, so the fact remains that you can't compare the noise in two images if one has undergone the gamma transition and one has not, because the gamma-transformed image will look artificially noisy.

I'm posting a figure to show the results of the calculation I did. As you can see, the noise gets spread wider in gamma signal space. (Please overlook the typo in the graph. It should say gamma, not bamma.)



Bottom line: You can't compare noise in linear signal space with noise in gamma signal space. Both have to be in the same signal space.

Since "it depends", one might as well play it safe and scan in 16 bits.

alanrockwood said:

To date in this discussion there has not been a comparison of a linear 16 bit results to a linear 8 bit result. There has only been a comparison of a linear 16 bit result to a gamma transformed 8 bit result, And this is why a proper comparison has not yet been done.

Click to expand...

Then explain the results for post #201. If the 8 bit acquire save 8 bit raw were really gamma encoded as you contend, I'd expect at least the same ball park values as the 16 bit acquire save 8 bit raw as by your logic they'd both be gamma encoded. They're not even in the same ball park as each other. Not only that, but in post #168, I also provide an 8 bit scan saved as a standard 8 bit tiff, which should be gamma encoded because it's not being saved as raw, and it also has very different values than the 8 bit acquire save 8 bit raw scan as well. If the 8 bit saves (raw or otherwise) are always being gamma encoded, then why the difference?

I don't doubt that you're seeing gamma encoded results with your own scans and I don't doubt the veracity of your commitment to that position, however, I am extremely doubtful that it's happening in every instance based on my own results.

Adrian Bacon said:

Then explain the results for post #201. If the 8 bit acquire save 8 bit raw were really gamma encoded as you contend, I'd expect at least the same ball park values as the 16 bit acquire save 8 bit raw as by your logic they'd both be gamma encoded. They're not even in the same ball park as each other. Not only that, but in post #168, I also provide an 8 bit scan saved as a standard 8 bit tiff, which should be gamma encoded because it's not being saved as raw, and it also has very different values than the 8 bit acquire save 8 bit raw scan as well. If the 8 bit saves (raw or otherwise) are always being gamma encoded, then why the difference?

I don't doubt that you're seeing gamma encoded results with your own scans and I don't doubt the veracity of your commitment to that position, however, I am extremely doubtful that it's happening in every instance based on my own results.

Click to expand...

Do some scans of scenes, preferably with a fairly dominant peak. do them in 16 to 16 tiff, 16 to 16 RAW, 16 to 8 Raw and 8 to 8 raw (can throw in an 8 bit TIFF if you want as well.) Compare both the images and the histograms. You will see that the TIFFs (whether 16 bit or 8 bit TIFFs) and the 8 bit RAWs have similar look, both in the images themselves and in their histograms, not necessarily identical, but pretty close. The outlier will be the 16 bit RAW. For the 16 bit RAW file the scene will look dark and the main peak in the histogram will be shifted left (toward black). This is exactly what is predicted if the 8 bit RAW scans are gamma encoded, and it is what I see. I have done this multiple times, and I'm very sure you will get the same results

In my opinion the only reasonable explanation for this is that 8 bit RAW scans are gamma encoded regardless of whether the input parameter was specified as 16 bit or 8 bit. And this is consistent with the information available on the online documentation at the Hamrick website which says that 8 bit RAW files are gamma encoded. The online documentation does not split this into whether the 8 bit RAW scans were acquired in 16 bit or 8 bit input. For lack of distinction between those two cases the best assumption is that the online documentation applies to all 8 bit RAW files. This may seem to contradict what Hamrick told you in the emails, but the experimental results don't lie.

Please, do the experiment described above yourself. It will take you no more than 15 minutes at most, and then rather than challenge my results without supporting information you can see for yourself.

Well, I'll be darned. Consider me officially brushed off by Vuescan's creator. I'm not going to beat around the bush here. It would appear that the information dispensed to me regarding Vuescan's behavior by its creator is incorrect. Kudos to @alanrockwood for sticking to his guns.

8 bit acquire, 8 bit save raw


16 bit acquire, 8 bit save raw


If Vuescan was in fact not gamma encoding 8 bit acquire and 8 bit raw save, then these two histograms should not match, but as a matter of fact, they mostly do. If I toggle between them, there's a difference down on the lower end, but I suspect that is due to the difference of less noise and more dynamic range on the 16 bit acquire.

I've also done the exercise with saving to tiff files and arrived at the same place, though there is a slight difference between 8 bit raw saves and 8 bit tiff saves due to the fact that sRGB isn't actually a straight 2.2 TRC. That being said, yes, in fact, 16 bit acquire with 16 bit raw save is not gamma encoded, it really does appear to be just a straight sensor dump to disk, so that's good.

I still would like to get some answers with regards to the wildly different noise floor levels I've seen with my own testing, but I think in the interest of this thread, that is a different subject, and maybe a different thread after I get the time to really poke around at it.

So where does that leave us?

Well, I personally don't recommend trying to determine noise and dynamic range differences between acquiring at 8 bits and acquiring at 16 bits on files that have been conformed to a color space simply because that introduces a lot of transforms to the sensor samples that can distort things, and 8 bit raw saves from 8 bit acquires appear to have the straight 2.2 gamma applied to them, so I guess I'm gonna have to write a little code to convert a 16 bit raw save to one that has a 2.2 gamma applied to it to match the 8 bit raw save from an 8 bit raw acquire, then generate a raw 16 bit save with that applied and a raw 8 bit save from an 8 bit acquire so that we can realistically do some comparisons on the noise performance of the two acquisition modes.

Well, that's that. I don't have a time frame simply because writing that code simply takes time, so it'll have to happen when I can fit it in.

Adrian Bacon said:

Well, I'll be darned. Consider me officially brushed off by Vuescan's creator. I'm not going to beat around the bush here. It would appear that the information dispensed to me regarding Vuescan's behavior by its creator is incorrect. Kudos to @alanrockwood for sticking to his guns.

8 bit acquire, 8 bit save raw
View attachment 301840

16 bit acquire, 8 bit save raw
View attachment 301841

If Vuescan was in fact not gamma encoding 8 bit acquire and 8 bit raw save, then these two histograms should not match, but as a matter of fact, they mostly do. If I toggle between them, there's a difference down on the lower end, but I suspect that is due to the difference of less noise and more dynamic range on the 16 bit acquire.

I've also done the exercise with saving to tiff files and arrived at the same place, though there is a slight difference between 8 bit raw saves and 8 bit tiff saves due to the fact that sRGB isn't actually a straight 2.2 TRC. That being said, yes, in fact, 16 bit acquire with 16 bit raw save is not gamma encoded, it really does appear to be just a straight sensor dump to disk, so that's good.

I still would like to get some answers with regards to the wildly different noise floor levels I've seen with my own testing, but I think in the interest of this thread, that is a different subject, and maybe a different thread after I get the time to really poke around at it.

So where does that leave us?

Well, I personally don't recommend trying to determine noise and dynamic range differences between acquiring at 8 bits and acquiring at 16 bits on files that have been conformed to a color space simply because that introduces a lot of transforms to the sensor samples that can distort things, and 8 bit raw saves from 8 bit acquires appear to have the straight 2.2 gamma applied to them, so I guess I'm gonna have to write a little code to convert a 16 bit raw save to one that has a 2.2 gamma applied to it to match the 8 bit raw save from an 8 bit raw acquire, then generate a raw 16 bit save with that applied and a raw 8 bit save from an 8 bit acquire so that we can realistically do some comparisons on the noise performance of the two acquisition modes.

Well, that's that. I don't have a time frame simply because writing that code simply takes time, so it'll have to happen when I can fit it in.

Click to expand...

Adrian, I'm glad that we have made progress working on this more or less together, though with a few bumps in the road along the way. Good luck with the coding when you are able to work it into your schedule.

I have a question that may or may not be related. Photoshop Elements converts 16 bit files into 8 bits for many of their processing adjustments. I forget which edits do that at this time. So my question is, if you scan at 16 bits, but the post-processing program edits in 8 bits, should we expect any major differences in the results?

Alan Edward Klein said:

I have a question that may or may not be related. Photoshop Elements converts 16 bit files into 8 bits for many of their processing adjustments. I forget which edits do that at this time. So my question is, if you scan at 16 bits, but the post-processing program edits in 8 bits, should we expect any major differences in the results?

Click to expand...

It depends on the nature of the edits. If it's color negative film that you scanned as a positive and you still need to invert it and fix the contrast and colors, 8 bits isn't very good for that.

Adrian Bacon said:

It depends on the nature of the edits. If it's color negative film that you scanned as a positive and you still need to invert it and fix the contrast and colors, 8 bits isn't very good for that.

Click to expand...

I would scan setting the scanner for negative film scans, not as a positive film that's inverted. Would that make a difference?

Alan Edward Klein said:

I would scan setting the scanner for negative film scans, not as a positive film that's inverted. Would that make a difference?

Click to expand...

Does it output a positive image, or is the image still a negative?

alanrockwood said:

Adrian, I'm glad that we have made progress working on this more or less together, though with a few bumps in the road along the way. Good luck with the coding when you are able to work it into your schedule.

Click to expand...

+1

Interestingly, doing a very counter-intuitive acquiring at 8 bits but saving at 16 bit raw (not tiff) doesn't seem to have the same gamma applied as saving at 8 bits, so it might be possible to compare acquiring 8 bits and acquiring 16 bits if they both have 16 bit raw as the output. That would potentially save me from writing some code.

Adrian Bacon said:

Does it output a positive image, or is the image still a negative?

Click to expand...

Epsonscan when set to scan negative color film reverses the output so you get the positive image file from the scan. The first and second picture in post #198 are examples of two of these scans of 6x7 Protra negative film (same frame). The first was scanned "flat" or "raw", with no adjustments applied. I believe the V600 used a gamma of 2.2 but I could be incorrect. In the second picture, I set the black and white points at each end of the available data in the histogram. The third picture is the one in post #199 (the results of "flat" or raw scan. Then, I applied Auto Levels in Elements to this resultant scanned file. It seems to give the best results. I don;t know if the result became 8 bits or was left at 16 bits.

OF course if you select positive scan, and scan a negative, then the resulting file will leave the negative as a negative and you would have to reverse it in post-processing. I've never tried this method.

Adrian Bacon said:

+1

Interestingly, doing a very counter-intuitive acquiring at 8 bits but saving at 16 bit raw (not tiff) doesn't seem to have the same gamma applied as saving at 8 bits, so it might be possible to compare acquiring 8 bits and acquiring 16 bits if they both have 16 bit raw as the output. That would potentially save me from writing some code.

Click to expand...

That's very interesting.

Another possibility is to use the gamma adjustment in a histogram window in an image processing program. That can be used to provide an approximate result. I don't know if it's close enough to the correct transformation form to be useful for doing the comparison at low signal levels. I have experimented with it, and it seems to be able to make a gamma transformed image look a lot like one that has not been transformed, but I could not get a perfect match to the overall appearance of an image. However, it might be worth experimenting with a bit because it could negate the need to write code, or if not it could be used as at least a rough check on code.

I think one difficulty in writing code is that you don't know what transformation vuescan does when creating an 8 bit RAW. It might be one of the ones on the list in the color tab, or it might be a proprietary one the Hamrick uses. He could probably get away with using his own proprietary one because his raw files are mostly intended to be used by his own program rather than external programs, so there is not a strong need to make it compatible with other standards used in the external world.

alanrockwood said:

That's very interesting.

Another possibility is to use the gamma adjustment in a histogram window in an image processing program. That can be used to provide an approximate result. I don't know if it's close enough to the correct transformation form to be useful for doing the comparison at low signal levels. I have experimented with it, and it seems to be able to make a gamma transformed image look a lot like one that has not been transformed, but I could not get a perfect match to the overall appearance of an image. However, it might be worth experimenting with a bit because it could negate the need to write code, or if not it could be used as at least a rough check on code.

I think one difficulty in writing code is that you don't know what transformation vuescan does when creating an 8 bit RAW. It might be one of the ones on the list in the color tab, or it might be a proprietary one the Hamrick uses. He could probably get away with using his own proprietary one because his raw files are mostly intended to be used by his own program rather than external programs, so there is not a strong need to make it compatible with other standards used in the external world.

Click to expand...

Well, with further testing, it appears that the acquire 8 bit save 16 bit raw does save 16 bits with no gamma applied, but it doesn't seem to scale it and instead just pads the top 8 bits out with zeros. If it was scaling it, I'd have no values below 257, and when capturing a black frame, the max value seen is 96.... That doesn't seem right.

Also, in an effort to see what gamma is actually being applied when saving 8 bit raw, the gamma for the output color space is what is used, not the straight 2.2 gamma that Hamrick says. You can see the differences by simply doing one scan with sRGB as the output color space, then one with ProPhoto as the output color space. They are not the same gamma and don't look the same between scans.

The closest thing to a straight 2.2 gamma with no linear section on the bottom is Adobe RGB.

Alan Edward Klein said:

Epsonscan when set to scan negative color film reverses the output so you get the positive image file from the scan. The first and second picture in post #198 are examples of two of these scans of 6x7 Protra negative film (same frame). The first was scanned "flat" or "raw", with no adjustments applied. I believe the V600 used a gamma of 2.2 but I could be incorrect. In the second picture, I set the black and white points at each end of the available data in the histogram. The third picture is the one in post #199 (the results of "flat" or raw scan. Then, I applied Auto Levels in Elements to this resultant scanned file. It seems to give the best results. I don;t know if the result became 8 bits or was left at 16 bits.

OF course if you select positive scan, and scan a negative, then the resulting file will leave the negative as a negative and you would have to reverse it in post-processing. I've never tried this method.

Click to expand...

If you're getting a positive image on the output, and not doing a lot of post otherwise, then 8 bits is probably fine for most uses.