Minolta 5400 or Coolscan V

[Kennedy McEwen]

As I say, it's no big deal (~15-20 clicks on the 16-bit scale) but it
just caught my eye... Do you notice anything similar on your LS4000
i.e. a channel being "short"?

I haven't noticed anything similar.

BTW, did you know there is *no* LS-50 scanner profile!?

NS4 only installs LS2000, LS4000 & NS8000 profiles. I tried them all
but none of them made much difference (i.e. no improvement) to the
notorious KC cast. Back to the drawing board... :-(

Check your Program Files/Common Files/Nikon/Profiles folder.

Something, and I assume it has been NS4, has installed the following
LS50 profiles on my machine:
NKLS50.icm
NKLS50_K.icm
NKLS50_MN.icm
NKLS50_N.icm
NKLS50_P.icm
NKLS50_R.icm

I don't believe that NS will run correctly unless it finds the correct
profile for the scanner it detects.

So far as I have ascertained, these files adhere to the ICC
specification which you can find at http://www.color.org/icc_specs2.html
The most recent version is ICC.1:2004-10, but earlier versions are also
available at that link.

I am sure that you can modify the NKLS50_K.icm profile to get precisely
the Kodachrome profile on you want, but you will need to save it with
the same name to be sure that NS4 recognises.

 

[Don]

Check your Program Files/Common Files/Nikon/Profiles folder.

Something, and I assume it has been NS4, has installed the following
LS50 profiles on my machine:
NKLS50.icm
NKLS50_K.icm
NKLS50_MN.icm
NKLS50_N.icm
NKLS50_P.icm
NKLS50_R.icm

Yes, I realized that almost immediately after I wrote the above.

Namely, NS4 lives on my W2K installation (which I haven't used since I
wrote my program). So, since I normally use W98 which only has NS3
installed no wonder LS50 profiles are missing on the W98 installation!

I don't believe that NS will run correctly unless it finds the correct
profile for the scanner it detects.

So far as I have ascertained, these files adhere to the ICC
specification which you can find at http://www.color.org/icc_specs2.html
The most recent version is ICC.1:2004-10, but earlier versions are also
available at that link.

Yup, thanks! Did that yesterday as well! The version I got is
"ICC1V42.pdf". However, I already found 2.5 errors in the format
description. :-( I spent all day yesterday unraveling the files.

I am sure that you can modify the NKLS50_K.icm profile to get precisely
the Kodachrome profile on you want, but you will need to save it with
the same name to be sure that NS4 recognises.

Even though they are nominally ICC, Photoshop doesn't recognize them.
I'm not yet sure why. Next, I plan to compare to Nikon profiles which
Photoshop does recognize (like the "NKLS4000LS40.icm").

Otherwise, the whole ICC profile format is yet another "Russian doll"
syndrome (i.e. "things" within "things")... Another steep learning
curve, from M curves (you mentioned before) to TRCs, etc... Ugh...

I've extracted the curves empirically a few days ago, but now I want
to actually get the raw curve data from the profiles themselves. This
is not easy because (unlike the straightforward gamma LUTs) profile
curves (e.g. AToB0Tag) are much more complicated.

Once/If I extract them I can then continue to scan raw. If at a later
date I choose to apply the (modified) profiles I can do that. If not,
I still have raw data to go back to. In theory I could even tag a file
with the scanner profile (instead of converting as NS4 does).

I don't know how much sense all this makes but it'll keep me off the
streets for a while. Alas, it pushes back the scanning, yet again. :-(

Don.

P.S. The only non-standard thing I noticed in NKLS50.icm is the
"profileDescriptionTag". According to the docs this should contain the
"multiLocalizedUnicodeType" i.e. "mluc', but instead it contains
'desc'. Since it's only a description it shouldn't matter, but...

 

[Don]

P.S. Another handy program:

http://www.color.org/membersonly/profileinspector.html

I've had it for a while, but never really used it until now. Anyway,
it will not only display the curves embedded in the profiles but will
also dump them to a text file. (Beats wading through hex dumps...)

Speaking of hex dumps, the reason PS refuses to recognize "NKLS50.icm"
and friends, is because they have an "unknown" device class
designation. For LS50 Nikon switched to "nkpf" which is, apparently,
not recognized by the ICC. Once I (hex) edited this into "scnr" PS is
happy to take them.

Now, I don't know how much sense doing that makes but their effect in
PS is very "mild". Nothing like what comes out of NS4. Indeed, in NS4
I noticed very harsh red cast in the shadows (even dark midtones!) but
the blue in (light) midtones and highlights is as solid as ever... :-(

I don't know... I have this deja vu feeling I'm getting bogged down in
yet another time consuming, yet futile, distraction. In other words,
chasing my tail again only to end up at square one.

It does remind me why I wrote my own scanning program, though! ;o)

Anyway, back to the salt mines...

Don.

 

[Kennedy McEwen]

P.S. Another handy program:

http://www.color.org/membersonly/profileinspector.html

Useful. Certainly saves having to 'roll your own', as I did.

Anyway, you might want to compare the curves in NKLS5****.icm with those
in NKLS4****.icm. Now there is certainly more than one way to skin a
cat, but why did Nikon change this between the 4-series to the 5-series?
And what would happen if you changed the identifiers round to make 5
series profiles be read by 4 series scanners or vice versa? ;-)

 

[Don]

Useful. Certainly saves having to 'roll your own', as I did.

Yes, I was just about to try to do that too (after examining the hex
dump) when I remembered this program.

Anyway, you might want to compare the curves in NKLS5****.icm with those
in NKLS4****.icm. Now there is certainly more than one way to skin a
cat, but why did Nikon change this between the 4-series to the 5-series?

I did have a cursory compare when I discovered what the Profile
Inspector can do and was surprised at how different some are e.g.
NKLS4000LS40.icm and NKLS50.ICM which, if I'm correct, are supposed to
be equivalent. Maybe that's why Nikon changed the device class so
LS50* profiles can *not* be used in Photoshop? In other words, Nikon
may be processing them internally in some non-standard way?

I did try all other profiles in PS (does it make sense to do that?)
but they don't seem to do what I expected. But it was a very cursory
glance. All this is new, and there's so much so I'm a bit swamped.

BTW, do you know what the various profiles are for? The names are
suggestive (K=KC, N=negative, R=reverse?, P=positive?) but I've only
been focusing on the K profile and it does indeed contain the (by now
familiar) characteristic curve. However, the curve is "inverted"
because of the way profiles work. Unlike LUTs which are a direct
replacement, profiles have two curves, input and output. And since the
output curves in the K profile is flat, the input curve is "inversed".

Speaking of which, what's the canonical way of inverting a curve? I
can think of a couple of "pragmatic" ways, but what the "proper"
mathematical way to invert them? I want to convert them into LUTs.

Also, just out of curiosity, if the above guesses are correct, do you
happen to know what's the odd one out, the mysteriously named MN?

And what would happen if you changed the identifiers round to make 5
series profiles be read by 4 series scanners or vice versa? ;-)

I know! ;o) I love doing things like that too! Actually, that's what I
was playing with before I realized where the LS50* profiles were. I
applied the 2K, 4K & 8K profiles in Photoshop for some "interesting"
results!

Also, I did some thinking. I know... I know... I shouldn't that, it
only gets me into trouble... ;o)

Seriously though, my scanner program doesn't use profiles. It does use
TWAIN, however, but TWAIN doesn't know anything about profiles. (If it
did, then it would complain since I don't have LS50* profiles on W98
where my program runs). So, how does TWAIN do KC, then? Either the KC
profile curves are embedded in the TWAIN or the firmware may have more
stuff than I thought? The more likely TWAIN route raises other
questions: Why are the results different? What I means is this:

The results from my program are "cleaner" than NS (see below) but KC
doesn't go far enough.
NS, on the other hand, does a better job re KC (although it could go a
bit farther still) but it does "weird things" with an "aggressive" red
cast resulting in a "dirty" scan!? Weird? I should post some examples.

As always: Too much to do, too little time...

Don.

 

[Don]

I'm only interested in exposure blending and Photomatix does this well.

Well, "exposure blending" is *conceptually* really a poor man's HDR
with a series of only 2 images. Any proper HDR program can "blend"
only two images with its eyes closed... ;o)

However when I tried doing this on 4000dpi scans I had problems
because Vuescan and my scanner aren't completely consistent and are
sometimes a pixel short in one dimension.

That's very common with multi-pass multi-scanning (i.e. when the
scanner does one image and then goes back and scans another). Some
scanners are better at it than others but there is bound to be some
misalignment. What's more it's not in the nice full pixel chunks but
in sub-pixels fragments!

That's why aligning images before blending is essential! Personally,
this alignment has caused me grief to no end (in the past)! :-(

The frustrating thing is that every scanner is capable of single-pass
multi-scanning but the manufacturers intentionally "disable" this!
Darn marketroids! It's perfectly feasible to have the scanner perform
two (or more!) exposures per line and "blend" them all before output
thereby resulting in a scanner with a virtually unlimited dynamic
range!! Even the darkest Kodachromes would be powerless against that!

Photomatix rejects these scans and I'm not sure what to do about this.
I tried resizing in Photoshop but the resulting blend looked like mush
up close (still better than HDR Shop's mush with color fringing...).

When the images are *not* the same size most programs don't go through
the trouble of aligning them. The reason it looks like mush is because
by changing the size you've moved the image and then the two are (even
more?) misaligned!

As to HDR Shop, you must be doing something terribly wrong to have all
these problems. It's a very solid program. My main beef was the 8-bit
input but considering it was written as a demonstration for a
scientific paper about 10 years ago - it's pretty amazing!

If you post images and/or specifics maybe we can locate why you're
having problems.

Don.

 

[Don]

In that case just remember that HDRShop in my experience doesn't
auto-align

That tells more about your "experience" than about HDR Shop:

--- start ---
....it does not scan precisely the same area of each negative relative
to the extents of the image. To counteract this effect, we
geometrically registered the images to each other using normalized
correlation to determine, with sub-pixel accuracy, corresponding
pixels between pairs of images.
--- end ---

"Geometrically registered images...", "using normalized
correlation...", ***with sub-pixel accuracy***... Need I say more?

I won't even bother with:

HDRShop doesn't allow to do exposure blending

because is just plain silly. It's like saying a 4000 dpi scanner
"doesn't allow" 100 dpi scans.

Don.

 

[Kennedy McEwen]

I did have a cursory compare when I discovered what the Profile
Inspector can do and was surprised at how different some are e.g.
NKLS4000LS40.icm and NKLS50.ICM which, if I'm correct, are supposed to
be equivalent.

They are, but the profiles are implemented in a different way for the
two scanners.

Maybe that's why Nikon changed the device class so
LS50* profiles can *not* be used in Photoshop? In other words, Nikon
may be processing them internally in some non-standard way?

I don't think so, after all, the device class is the same for 4-series
profiles as for 5-series. However the two types appear to be used
differently by NS4, depending on the scanner detected.

I did try all other profiles in PS (does it make sense to do that?)
but they don't seem to do what I expected. But it was a very cursory
glance. All this is new, and there's so much so I'm a bit swamped.

There are some strange effects. NS seems to load the profiles up when
initiated, so changing profile requires NS to be closed and restarted.

BTW, do you know what the various profiles are for? The names are
suggestive (K=KC, N=negative, R=reverse?, P=positive?) but I've only
been focusing on the K profile and it does indeed contain the (by now
familiar) characteristic curve. However, the curve is "inverted"
because of the way profiles work. Unlike LUTs which are a direct
replacement, profiles have two curves, input and output. And since the
output curves in the K profile is flat, the input curve is "inversed".

Yes, you'd think that, wouldn't you, but it doesn't seem to be quite as
straight forward. ;-)

I tried removing the profiles from the directory and then replacing them
to see their effect on NS. With all of the profiles for the detected
scanner removed, NS crashes - which I mentioned the other day. However,
with either nkls4000ls40_p.icm *or* nkls4000ls40_k.icm loaded, it will
happily scan as a positive or as KC! In other words, the *_k file does
not even seem to be needed to scan KC, as long as the *_p file is there,
and the *_p file is not needed to scan positive if the *_k file is
present.

*_n files are required for negatives - colour and monochrome, whilst the
*_r files seem to be linear profiles, probably for use with NCM off. But
I have no idea what the file without any underscore postscript is used
for - my scanner seemed to work fine without it when I briefly checked.

Also, just out of curiosity, if the above guesses are correct, do you
happen to know what's the odd one out, the mysteriously named MN?

Well, this seems to be the difference between the way that 4-series
scanners are treated from 5-series. The 4-series don't seem to have an
associated MN file, which has the Tone Reproduction Curves for the
5-series scanners. The TRCs seem to be "built in" to the profiles for
the 4-series, which is why they are significantly different.

Seriously though, my scanner program doesn't use profiles. It does use
TWAIN, however, but TWAIN doesn't know anything about profiles. (If it
did, then it would complain since I don't have LS50* profiles on W98
where my program runs).

Are you sure about that? NS is just an applet that accesses TWAIN. If
I remove the profiles for my scanner from the directory they are in then
neither NS nor TWAIN function - and I still run W98.

So, how does TWAIN do KC, then?

Probably because you are running without NCM enabled and scanning raw -
no profile is actually being applied.

Either the KC
profile curves are embedded in the TWAIN or the firmware may have more
stuff than I thought? The more likely TWAIN route raises other
questions: Why are the results different? What I means is this:

The results from my program are "cleaner" than NS (see below) but KC
doesn't go far enough.

Does it do anything at all, though?

NS, on the other hand, does a better job re KC (although it could go a
bit farther still) but it does "weird things" with an "aggressive" red
cast resulting in a "dirty" scan!? Weird? I should post some examples.

Eh? I thought you were complaining that KC was scanning too blue, not
too red!

 

[Don]

NOTE: "Exciting" scans below! ;o)

There are some strange effects. NS seems to load the profiles up when
initiated, so changing profile requires NS to be closed and restarted.

Yes, you'd think that, wouldn't you, but it doesn't seem to be quite as
straight forward. ;-)

I noticed! Nikon seem to follow the: "Why simple when it can be
complicated" rule. ;o)

I tried removing the profiles from the directory and then replacing them
to see their effect on NS. With all of the profiles for the detected
scanner removed, NS crashes - which I mentioned the other day. However,
with either nkls4000ls40_p.icm *or* nkls4000ls40_k.icm loaded, it will
happily scan as a positive or as KC! In other words, the *_k file does
not even seem to be needed to scan KC, as long as the *_p file is there,
and the *_p file is not needed to scan positive if the *_k file is
present.

Huh? That's pretty weird! It seems to suggest there is more to both
TWAIN and possibly (?) firmware. I really wish I had the time to
finish disassembling the TWAIN and see what actually does it do with
the KC mode on. I started all this, a few months ago, but wading
through disassembled C code is sheer torture as C builds temporary
storage on stack and then calls several layers of subroutines.

I did, however, find a way to increase exposure and hex-edited my
version of NS4 to increase exposure in all channels to +16 (just an
arbitrary number). Curiously, and slightly to my surprise, NS4 has no
problem with this (!) and the exposure sliders increase (are lopsided)
to reflect the +16 (instead of +2) exposure range!! So, at least in
this respect, NS4 has been programmed properly i.e. the exposure is
not hardcoded in NS4 but read from TWAIN.

(!) However, for the purpose of all these tests I'm using the original
TWAIN to eliminate that as a possible problem.

*_n files are required for negatives - colour and monochrome, whilst the
*_r files seem to be linear profiles, probably for use with NCM off. But
I have no idea what the file without any underscore postscript is used
for - my scanner seemed to work fine without it when I briefly checked.

I haven't tried all the profile permutations with NS (I really
should...) because I have been focusing on getting the curves out
first. But there are some odd things going on.

Well, this seems to be the difference between the way that 4-series
scanners are treated from 5-series. The 4-series don't seem to have an
associated MN file, which has the Tone Reproduction Curves for the
5-series scanners. The TRCs seem to be "built in" to the profiles for
the 4-series, which is why they are significantly different.

I see. I suppose - in theory - they probably did that to be more
flexible? I see 9000 also has an MN profile.

Are you sure about that? NS is just an applet that accesses TWAIN. If
I remove the profiles for my scanner from the directory they are in then
neither NS nor TWAIN function - and I still run W98.

Yes, and I just repeated everything. This is the context: I have two
removable disks in my notebook: C with W98, and D with W2K (I can plug
both of them in simultaneously, but that's beside the point).

W98 has NS3 and no LS50* profiles anywhere. W2K has NS*4* and LS50
profiles.

On the W2K I renamed all LS50* profiles to xLS50*, turned on the
scanner and ran NS4. It hung for a very long time and then just exited
without any error or message of any sort (it should've really
complained about missing profiles).

Next, I rebooted into W98 and ran my program using the "custom" TWAIN
with boosted exposure which lives in the same directory as my program.
It scanned without any problems.

NS likes to "hide" things all over the place so just to be sure I did
a global search for LS50* profiles on the W98 machine and couldn't
find them anywhere i.e. the TWAIN used by my program is "flying solo".

So, it seems, TWAIN has *some* support (like the KC mode) built-in and
doesn't actually use profiles. That's probably why you can scan when
you remove the K profile but leave the P profile in (and vice versa).

Probably because you are running without NCM enabled and scanning raw -
no profile is actually being applied.

But TWAIN must be getting the KC curves from somewhere because I can
still select between KC and P in my program. It's a functionality
built into the TWAIN itself (we know that because there are TWAIN
calls to set the KC mode and it doesn't use profiles).

Which is puzzling because if the KC mode is built into TWAIN then why
duplicate it with an explicit K profile!? The same goes for negatives?
It appears NS itself "does things" in addition to TWAIN and thereby
bypassing duplicate (?) TWAIN functions!?

Does it do anything at all, though?

Yes! The KC scan in my program is clearly different from Positive (see
below for examples). So, clearly KC mode in TWAIN does something. But
this "something" is different from KC mode in NS4 which appears to do
things "on top of" TWAIN KC mode.

Now, my program doesn't use profiles while NS4 does. Therefore the
difference appears to be that NS4 applies the KC mode + scanner
profile, while my program only uses the KC mode function of TWAIN.

That's why I wanted to extract all those profile curves to confirm all
this by applying them selectively to scans from my program. But then I
ran into another problem, in that these curves seem to behave
differently in PS than they do in NS. That's, probably, because - as
you write above (!) - things are not that straight forward...

Eh? I thought you were complaining that KC was scanning too blue, not
too red!

Actually, it's both! When I use NS4 I get the "too blue" in the
highlights as usual, but then in addition I also get "too red" even in
dark midtones (let alone shadows)!? Here's what I mean:

The context: Both NS4 and my program use the same settings except NS4
does the following as well:
- AE (I set the exposure manually)
- profiles (I don't use them and apparently neither does TWAIN)

All images were cropped and saved in PS6, working profile: sRGB.

First the NS4 scans. Settings: Factory default monitor profile,

using sRGB color space:
http://members.aol.com/tempdon100164833/ns4/NS4_K_sRGB.jpg
http://members.aol.com/tempdon100164833/ns4/NS4_P_sRGB.jpg

and then "just-for-fun" using 'scanner profile' i.e. no profile:
http://members.aol.com/tempdon100164833/ns4/NS4_K_scanner.jpg
http://members.aol.com/tempdon100164833/ns4/NS4_P_scanner.jpg

Next, my scans. Manual exposure set to +2.0 AG which is roughly
equivalent to NS4 auto exposure for the slide:

http://members.aol.com/tempdon100164833/ns4/Don_K_2.0AG.jpg
http://members.aol.com/tempdon100164833/ns4/Don_P_2.0AG.jpg

Now, compare NS4_K_sRGB.jpg and Don_K_2.0AG.jpg which are equivalent.
Specifically, the shadow part of the wall on the right.

In the NS scan this shadow is quite bad with very pronounced *purple*
spots (and I'm not talking about grain!). BTW, that purple wall is
what tipped me over to write my own program. I just couldn't bring
myself to archive that.

Compare to my scan, which is nominally more blue, but the wall is much
"cleaner", much more "even". It's certainly easier to remove the blue
cast from my scan than it is to remove (albeit less pronounced) blue
*and* purple (!) casts from the NS scan.

Finally, even though the NS scan appears darker I don't think that's
the result of different exposure but due to NS4 setting the black
point and all sorts of other things as it applies the (scanner?)
profile. Well, that's my guess after examining the profiles... But you
know much more about this than I do.

The remaining scans are for reference.

What do you make of it all?

Don.

 

[JJackson382]

I tried manually blending two scans to extend the dynamic range in PS,
and quickly gave up. Aligning the two layers precisely is darn near
impossible. In some cases masking out portions in one layer by painting
can be a pain. Last but not least, creating a natural looking blend may
take several trial and error scans with different exposures. If HDR can
do these automatically or with ease, I want to learn about it. Where can
I find an intro tutorial? Thanks.

 

[Don]

I tried manually blending two scans to extend the dynamic range in PS,
and quickly gave up. Aligning the two layers precisely is darn near
impossible.

Yes, it's a major chore. Not only are sub-pixel misalignments a big
problem but I recently discovered that misalignments are not uniform.

What I mean by this is that if the image is, say, off to the left at
one end, it's often off to the right at the other! So not only does
the image need to be (sub-pixel) aligned but it needs to be
transformed too!

And then if that weren't bad enough this misalignment occurs on both
axis. On the face of it this appears impossible because the CCD cells
don't change position (like the steps of the stepper motor on the
other axis do).

I don't know why there is misalignment on the CCD axis but I suspect
it may be because the film "floats" as it moves and it "wiggles' from
side to side changing the angle at which the CCD array scans it. This
then results in scan lines of different length i.e. misalignment.

In some cases masking out portions in one layer by painting
can be a pain. Last but not least, creating a natural looking blend may
take several trial and error scans with different exposures. If HDR can
do these automatically or with ease, I want to learn about it. Where can
I find an intro tutorial? Thanks.

I don't have any specific and comprehensive tutorial to suggest
because I learned about all this from various (mathematical) sources.
The two key terms are "convolution" and "correlation" but it's very
heavy going...

I ended up implementing a method whereby I have 4 "anchors" in 4
corners of the image and then transform the image accordingly. But, as
outlined above, I'm now noticing that the misalignment is not uniform
but it fluctuates. I suppose the next step is to figure out the
fluctuation range so I can increase the number of "anchors".

What's frustrating is that all this could be easily solved (more
accurately too!) if only scanner manufacturers would allow access to
the scanner at each scan line! One would then perform two exposures
before the scanner moves on to the next line and eliminate the need
for alignment completely!

Don.

 

[Don]

The Konica-Minolta web-site is worthless for any technical information.

Actually, not if you know where to look. ;o)

Back on the 5400 page you can download the manual. It's called
"DS_Elite_5400_II_E_A.pdf" and I believe it lives here:

http://kmpi.konicaminolta.us/eprise...ges/DiMAGE_Scan_Elite_5400_II?mDetail=Manuals

That should answer most if not all of your questions.

I, for one, usually never bother with marketroid nonsense (for that
the web sites really are worthless!) and go straight to the manual.
Fortunately, these days most manufacturers offer them online.

Any other information that would help me make an informed decision would be
greatly appreciated.

There are two versions of the "5400". The original and the new Mark II
(i.e. the above manual). The original had a conventional light source
(must warm up, drifts over time, eventually burns out) while the new
one has a white LED (instantly available, doesn't drift, lasts
"forever").

Don.

P.S. I don't even have a Minolta but happened to be "just looking" the
other day.

 

[JJackson382]

Yes, it's a major chore. Not only are sub-pixel misalignments a big
problem but I recently discovered that misalignments are not uniform.

What I mean by this is that if the image is, say, off to the left at
one end, it's often off to the right at the other! So not only does
the image need to be (sub-pixel) aligned but it needs to be
transformed too!

And then if that weren't bad enough this misalignment occurs on both
axis. On the face of it this appears impossible because the CCD cells
don't change position (like the steps of the stepper motor on the
other axis do).

I don't know why there is misalignment on the CCD axis but I suspect
it may be because the film "floats" as it moves and it "wiggles' from
side to side changing the angle at which the CCD array scans it. This
then results in scan lines of different length i.e. misalignment.


I don't have any specific and comprehensive tutorial to suggest
because I learned about all this from various (mathematical) sources.
The two key terms are "convolution" and "correlation" but it's very
heavy going...

I ended up implementing a method whereby I have 4 "anchors" in 4
corners of the image and then transform the image accordingly. But, as
outlined above, I'm now noticing that the misalignment is not uniform
but it fluctuates. I suppose the next step is to figure out the
fluctuation range so I can increase the number of "anchors".

What's frustrating is that all this could be easily solved (more
accurately too!) if only scanner manufacturers would allow access to
the scanner at each scan line! One would then perform two exposures
before the scanner moves on to the next line and eliminate the need
for alignment completely!

Don.

Yes, I also find manually that aligning two scans calls for some sort of
transformation. Will HDR's auto alignment take care of this? Some
suggested using PanoTools to do this, but I have gone down that path.

To be clear, I was looking for HDR tutorials.

"I don't know why there is misalignment on the CCD axis but I suspect
it may be because the film "floats" as it moves and it "wiggles' from
side to side changing the angle at which the CCD array scans it. This
then results in scan lines of different length i.e. misalignment."

Will this also explain why portions of a film scan can be out of focus?

 

[Don]

"I don't know why there is misalignment on the CCD axis but I suspect
it may be because the film "floats" as it moves and it "wiggles' from
side to side changing the angle at which the CCD array scans it. This
then results in scan lines of different length i.e. misalignment."

Will this also explain why portions of a film scan can be out of focus?

I think that's due more to warped film. My old Kodachromes (in
cardboard mounts) usually "sag" in the middle. Depending on the
scanner's depth of field, focusing on the middle may bring the rest
out of focus, or at least soften it.

On my Nikon LS50 I find that anything within about +/- 2 clicks is in
focus, while anything within about +/- 4 clicks is sort of acceptable.
However, on my warped Kodachromes the difference between the middle
and the corners is often > 20 clicks!

This too - just like multiple exposures - could easily be taken care
of if only scanner manufacturers allowed access to the scanner at each
scan line!

Don.