Vuescan: dark frame subtraction

  • Thread starter Thread starter Fernando
  • Start date Start date
SNIP
So I have basically 1-bit out of 16 dark noise.
Click to expand...

OOPS, that's what you get when you don't go to sleep when you should
....
The Photoshop (15-bit +1) read-out was set to 8-bit RGB values.

Using another tool gave me the following 16-bit statistics:
Red: mean=148.556, stddev=70.381, median=148, highest bin=714
Green: mean=130.227, stddev=68.554, median=128, highest bin=694
Blue: mean=206.009, stddev=71.221, median=206, highest bin=802
So I have basically 7 to 7.7 bits out of 16 dark noise, leaving 8.3 to
9 bits DR with a single scan pass, including calibration defects.

I really should also test with multiple scans, e.g. 4x and 16x (if I
have nothing better to do), and I'll also DFS the darkframe itself,
which should result in an image of temporal noise. It is important to
get avery clean Darkframe because the subtraction will also add to the
noise floor, but without calibration defects. Later.

Bart
 
That's good. But my suggestion was that giving this address should be
your *only* contribution to the VueScan discussion;-)
Click to expand...

LOL! ;o) Very good!
On the other hand, most of us know that free downloadable version is
crippled, at least for people interested in the full version. But I
think we already agree on this.
Click to expand...

Indeed!

Don.
 
The C code looks well written and commented, and seems easy to follow
as I read it superficially. It ran with little impact (<10%) on the
processor cycles, but did slow down system response (high priority
process), maybe due to Hard Drive activity.
Click to expand...

Yes, unfortunately ImageMagick uses a peculiar kind of image
buffering... it stores huge (5 x image size) temporary files on the
hard disk and reads/writes portions of them while working (I think
it's called "pixel cache").
On large images It slows down the system a lot, but has the advantage
of using a reasonable quantity of RAM. Anyway, there's nothing I can
do about that, unfortunately...
Next, your program first reads the source file, then the dark file,
and then calculates the dark average. Although I didn't have any
problems with my two 311 MB files in a limited amount of available
memory, I'd prefer reading the dark file first, calculate the average,
and release the dark frame's memory leaving the average, and then read
the Source file.
Click to expand...

Yes; now I read the source file first, in order to get geometry
informations from it: or else, I could not check if the dark frame has
"compatible geometry".
But having seen how fast is the averaging routine, I could do it
anyway and check the geometries when reading the source image, later.

Thanks for taking the time to have a look at DFSub! :)

Fernando
 
Back
Top