X
XFer
Guest
(multi sampling support)
Usually scanner firmware exposes to the driver a set of commands which are relatively high level.
This has many advantages, from easier driver programming to less documentation to be given out to less chance for a bug in the driver to damage the scanner.
To move multi sampling out of the firmware and into the software (driver) you should expose to the driver very low-level commands (like: "advance film one step" - "acquire row" - "acquire row" - "acquire row" - etc.). I don't see a scanner manifacturer doing that.
Well it depends from film type and scene captured. Without separate RGB exposure you get -2 EV dynamic range for B and you have to compensate for this by boosting the B channel during negative inversion.
It may not affect a particular image in a visible way, but may be quite important for a different image.
It's not so easy to show this because of the way scanning softwares work (you can't easily tell a software "do not use different RGB exposure" 🙂 ). With Vuescan it is doable, but frankly, Vuescan is quite limited in treating color negatives.
I should perform raw scans with and without separate RGB exposure compensation, invert the raw scans with an appropriate software (Photoshop sucks badly at that) and avoid misrepresenting the results (for example because of different color balance corrections / gamma curve corrections).
I did some tests time ago, I'll see if I can dig them out. 🙂
Sadly, I think you're right. 🙁
Fernando
But is there a requirement that the code needs to live in the scanner (firmware)?
Usually scanner firmware exposes to the driver a set of commands which are relatively high level.
This has many advantages, from easier driver programming to less documentation to be given out to less chance for a bug in the driver to damage the scanner.
To move multi sampling out of the firmware and into the software (driver) you should expose to the driver very low-level commands (like: "advance film one step" - "acquire row" - "acquire row" - "acquire row" - etc.). I don't see a scanner manifacturer doing that.
Just yesterday I was goofing around on my 5400 with individual RGB gains and to be honest the difference was minimal (I don't think I would pass the blind test).
Well it depends from film type and scene captured. Without separate RGB exposure you get -2 EV dynamic range for B and you have to compensate for this by boosting the B channel during negative inversion.
It may not affect a particular image in a visible way, but may be quite important for a different image.
It's not so easy to show this because of the way scanning softwares work (you can't easily tell a software "do not use different RGB exposure" 🙂 ). With Vuescan it is doable, but frankly, Vuescan is quite limited in treating color negatives.
I should perform raw scans with and without separate RGB exposure compensation, invert the raw scans with an appropriate software (Photoshop sucks badly at that) and avoid misrepresenting the results (for example because of different color balance corrections / gamma curve corrections).
I did some tests time ago, I'll see if I can dig them out. 🙂
I can't see a scanner designer that thinks 5300dpi medium format scanner doesn't need autofocus to spend much time on providing adjustable RGB exposure times
Sadly, I think you're right. 🙁
Fernando