ScanMultiPro with Vuescan "Long exposure pass"

[kolwicz]

I've been getting serious artifacts when trying to use the "long
exposure pass" with the Minolta SMPro and finally contacted Ed Hamrick
who tells me that the setting doesn't work with some scanners due to
some CCD effect.

Well, it may not work at maximum exposure, "lock exposure/exposure" set
to 11, but you can get some effect of seeing into the darkest areas of
your transparencies by finding the maximum exposure setting that will
open the darks without artifacts. I found by repeated quick scans of a
black on white slide subject that exposure set at about 7.5 doesn't
screw-up the CCD and is some help opening the darks, although not as
effective at the max setting = 11. A setting of 8 gave artifacts, so it
is pretty sensitive and the threshold should be easy to find.

Of course to use this method you have to make at least 2 scans and
layer them together with an image editor, like Photoshop. That's not as
easy as using long exposure pass, but it's better than nothing and it
gives you the opportunity to merge the scans the way you prefer.

 

[Bart van der Wolf]

I've been getting serious artifacts when trying to use the "long
exposure pass" with the Minolta SMPro and finally contacted
Ed Hamrick who tells me that the setting doesn't work with
some scanners due to some CCD effect.

Yes, "blooming" as a result of (over)saturating the sensor elements
will affect neigboring sensors. That will make it harder to find an
artifact free transition between exposures. Also, the double scan pass
may not register very well, although several users have reported
succes (good repositioning by the hardware).

Well, it may not work at maximum exposure, "lock
exposure/exposure" set to 11, but you can get some effect
of seeing into the darkest areas of your transparencies by
finding the maximum exposure setting that will open the
darks without artifacts.

VueScan's longer exposure pass already attempts to overexpose by quite
a margin (scanner dependent). So locking an exposure at an already
"too high" level will likely cause more trouble. It's important to
first set a correct (non-saturating) exposure for the scan, and lock
exposure at that level. Then the second exposure will oversaturate the
sensor (causing some blooming unless the sensor array drains the
excess charge) but also penetrate the dense film areas.

For a successful blend of the two exposures, you'd best use linear
gamma output. You either drop the overexposed level by dividing that
exposure by the overexposure factor (yielding lower noise shadows), or
you apply a creative blend that effectively transitions between
overexposed dense film areas and correctly exposed
midtones/transparent film areas. Color balance may be hard to get
right if you scanned slides, because the densest parts of slides have
horrible accuracy.
Once you've blended the linear-gamma images, you need to apply a
tonemapping so the resulting range of luminances can fit within the
16-bit/channel range (often done by compression of the (output)
highlights), and gamma adjust for normal output.

Bart

 

[Don]

I've been getting serious artifacts when trying to use the "long
exposure pass" with the Minolta SMPro and finally contacted Ed Hamrick
who tells me that the setting doesn't work with some scanners due to
some CCD effect.

This has nothing to do with the CCD. The problem (as always) is
VueScan.

What you're trying to do is known as "multi-pass multi-scanning". As
you correctly state, one needs to make two separate scans. However,
such scans will virtually never be perfectly aligned. VueScan
blissfully ignores this (as well as the color shift!) and merges them
into a blurry mess...

You can get much better results (faster too!) than this VueScan
mutilation by simply applying a small amount of Gaussian Blur to dark
areas of the image in Photoshop. (Select with Threshold, use some
Feathering.)

However, to do this properly you need to sub-pixel align the images
first, then adjust the color shift (!) caused by different exposures
and only then merge.

Search the archives for "Twin scan" message where one such approach is
explained in detail. There have been some modifications since, but
that should get you started. Also, google for "contrast masking" and
"high dynamic range".

Finally, there's a free program which will do all this for you
automatically:

http://www.ict.usc.edu/graphics/HDRShop/

but it has some problems. For example, it limits input to 8-bit images
and also clips the highlights by about 3.9%.

Well, it may not work at maximum exposure, "lock exposure/exposure" set
to 11, but you can get some effect of seeing into the darkest areas of
your transparencies by finding the maximum exposure setting that will
open the darks without artifacts. I found by repeated quick scans of a
black on white slide subject that exposure set at about 7.5 doesn't
screw-up the CCD and is some help opening the darks, although not as
effective at the max setting = 11. A setting of 8 gave artifacts, so it
is pretty sensitive and the threshold should be easy to find.

In order to open up dark areas and eliminate noise it helps to use
absolute manual exposure setting rather than relative. In my
experience (Nikon LS-50, Kodachromes) the shadows scan needs to be
done at +5 EV. Establishing such absolute exposure for your scanner
can streamline your workflow because you don't have to guess the
shadows exposure each time.

The problem with VueScan is that it doesn't use EV but its own silly
"multiplier units". Even if you manage to convert EV to these VueScan
"units" you'll still have a problem because VueScan has a major
exposure bug (one of many). Any setting over 100 "units" produces a
random exposure and the setting is then secretly rolled back to 100!?
VueScan is really not suitable for this sort of thing (if one cares
for quality and reliability, that is) although it may be OK for
uncritical, casual use such as web graphics or small prints.

Don.

 

[Don]

Yes, "blooming" as a result of (over)saturating the sensor elements
will affect neigboring sensors.

That's totally irrelevant.

The overexposed part of the image is thrown away when this is done
properly. See any reference to HDR (e.g.
http://www.debevec.org/Research/HDR/debevec-siggraph97.pdf). Some of
the images used to generate an HDR image are so severely overexposed
that only fragments are still visible. However, it's those fragments
which are important and the rest is simply thrown away.

Even with only two images the overexposed image only contributes data
until about 36 but certainly not above 48 on the 8-bit histogram scale
- and that's at gamma 2.2! The blooming and clipping happens at the
other end of the histogram and is totally irrelevant.

It is "relevant" to VueScan, however, because VueScan is so sloppily
programmed and does such a poor job. In addition to ignoring both the
misalignment and color shift VueScan then goes on to just mesh these
images haphazardly and wantonly which is why the result of "long
exposure pass" is such a mess.

Don.

 

[UrbanVoyeur]

That's totally irrelevant.

The overexposed part of the image is thrown away when this is done
properly.

But that's not what blooming is entirely about - or so I thought.

I thought blooming occurs when you give an area of CCD sensor much more
light than it can handle and it affects the color and exposure of
neighboring adjacent areas. It does not necessarily drive the adjacent
areas to saturation or clipping, but it can obscure details and shift
colors.

So discarding the sensor saturated highlight data in this case will not
necessarily address all the problems caused by blooming. Though I guess
its also image dependent. I would think dark areas adjacent to very
light areas would be the most affected.

 

[Bart van der Wolf]

But that's not what blooming is entirely about - or so I thought.

I thought blooming occurs when you give an area of CCD sensor much
more light than it can handle and it affects the color and exposure
of neighboring adjacent areas. It does not necessarily drive the
adjacent areas to saturation or clipping, but it can obscure details
and shift colors.

Correct. Some sensors have anti-blooming circuitry which can be
switched on (usually at the expense of dynamic range) or off.

So discarding the sensor saturated highlight data in this case will
not necessarily address all the problems caused by blooming. Though
I guess its also image dependent. I would think dark areas adjacent
to very light areas would be the most affected.

Correct.

Bart

 

[Don]

I thought blooming occurs when you give an area of CCD sensor much more
light than it can handle and it affects the color and exposure of
neighboring adjacent areas. It does not necessarily drive the adjacent
areas to saturation or clipping, but it can obscure details and shift
colors.

So discarding the sensor saturated highlight data in this case will not
necessarily address all the problems caused by blooming. Though I guess
its also image dependent. I would think dark areas adjacent to very
light areas would be the most affected.

Doesn't make any difference. The "neighboring" areas are still too far
away.

Test 1: Scan a row of black and white stripes. The result should be a
square wave. It is not. Inspect the scan at an appropriate
magnification and you'll see a gradient between the black and white
stripes which offers more than enough elbow room for HDR blending.

That's an extreme case and even there it's irrelevant.

In real life HDR images blooming is even more irrelevant. If it were,
no HDR program could work.

Test 2: Take any reasonable HDR program. Feed it immensely overexposed
images, as a part of a series, where highlights are blown to high
heaven with blooming extending to a neighboring continent... Do you
see any blooming in the end result?

Again:
http://www.debevec.org/Research/HDR/debevec-siggraph97.pdf
Take a look at either series, the cathedral or the office. The last
images in the series are way overexposed. Indeed, that's the point! Do
you see any artifacts in the final product?

But let me bend over backwards. Let's say you're really picky and want
that very pixel right next to a blooming pixel.

No problem! All you need to do is increase the number in the HDR
series including an exposure where this area is captured correctly OR
simply change the merge threshold.

Blooming is totally irrelevant to HDR and is just an excuse to try and
hide VueScan's massive shortcomings. See response to Bart for more.

Don.

 

[Don]

Correct.

But utterly irrelevant!

What you call "blooming" is in reality a mismatch between two scans
because the VueScan's author does *not* sub-pixel align!!! Therefore,
the final result of VueScan's mutilation shows *ghosting* due to
*image misalignment*!

That has absolutely *nothing* to do with blooming!

This whole blooming straw man is a smoke screen thrown up to hide
massive programming incompetence by VueScan's author which his
uncritical fans, like yourself, swallowed whole.

Don.

 

[John]

This whole blooming straw man is a smoke screen thrown up to hide
massive programming incompetence by VueScan's author which his
uncritical fans, like yourself, swallowed whole.

Don.

Here is a quote from the Vuescan user guide with respect to the Long
Exposure Pass:

" Note that this option sometimes produces image artifacts near sharp
transitions between dark and light areas, and should be used with care. It
works better on some scanners than others, and it isn't recommended as a
default option."

In other words, Ed Hamrick never intended this to be a killer feature - just
something that might help some users some of the time, and probably before
there were many better alternatives. No-one is trying to hide anything.

Just being objective

 

[UrbanVoyeur]

Doesn't make any difference. The "neighboring" areas are still too far
away.

Test 1: Scan a row of black and white stripes. The result should be a
square wave. It is not. Inspect the scan at an appropriate
magnification and you'll see a gradient between the black and white
stripes which offers more than enough elbow room for HDR blending.

That's an extreme case and even there it's irrelevant.

If you scan a gradient white to gray to black stripes, at the border
between the blown out whites and gray, you may see fringing/color shifting

In real life HDR images blooming is even more irrelevant. If it were,
no HDR program could work.

It doesn't happen always, and some sensors are worse than others. Also,
some CCD's can tolerate more exposure than others before blooming. Its
also color dependent. I've noticed that blooming tends to occurs more
with yellows and reds than blues and greens.

Test 2: Take any reasonable HDR program. Feed it immensely overexposed
images, as a part of a series, where highlights are blown to high
heaven with blooming extending to a neighboring continent... Do you
see any blooming in the end result?

Yes. Happens all the time with specular highlights.

Again:
http://www.debevec.org/Research/HDR/debevec-siggraph97.pdf
Take a look at either series, the cathedral or the office. The last
images in the series are way overexposed. Indeed, that's the point! Do
you see any artifacts in the final product?

But let me bend over backwards. Let's say you're really picky and want
that very pixel right next to a blooming pixel.

No problem! All you need to do is increase the number in the HDR
series including an exposure where this area is captured correctly OR
simply change the merge threshold.

But what happens when the adjacent pixels areas that are affected by the
color shift carry the very detail you are trying to preserve?

 

[UrbanVoyeur]

But utterly irrelevant!

What you call "blooming" is in reality a mismatch between two scans
because the VueScan's author does *not* sub-pixel align!!! Therefore,
the final result of VueScan's mutilation shows *ghosting* due to
*image misalignment*!

That has absolutely *nothing* to do with blooming!

This whole blooming straw man is a smoke screen thrown up to hide
massive programming incompetence by VueScan's author which his
uncritical fans, like yourself, swallowed whole.

But I made no reference to scanner software. In the cases where I've
used long exposure, it has mostly been with Silverfast because they've
had HDR tools for while. And some scanners do exhibit more blooming than
others.

Its not uncommon in my photos to have highlights, esp specular, surround
by midtaones and darker detail. The point I was making was that blooming
affects adjadcent sensor area, skewing them in way that often not easily
correctable.

Even with a perfectly aligned HDR merger, the color and exposure shift
can produce artifacts like fringing or what sometimes looks like really
bad chromatic abberration. Even though the clipped highs are discarded,
the lower values are kept and that causes the problems in the merger. If
you discard values that are too low, you end up defeating the purpose of
the merger.

Its not always a problem, but it does exist.

 

[Don]

Here is a quote from the Vuescan user guide with respect to the Long
Exposure Pass:

" Note that this option sometimes produces image artifacts near sharp
transitions between dark and light areas, and should be used with care. It
works better on some scanners than others, and it isn't recommended as a
default option."

In other words, Ed Hamrick never intended this to be a killer feature - just
something that might help some users some of the time, and probably before
there were many better alternatives. No-one is trying to hide anything.

Actually, Bart is. He, of all people, should know better (with his
considerable knowledge) that blooming is not the issue in this
context. The key problem is that the VueScan scans are misaligned.

But Ed doesn't go free either, spreading misinformation (as witnessed
by the OP) by telling him that any problems he experienced are due to
blooming ("due to some CCD effect").

That's just patently wrong and clearly an attempt to hide the fact
that Ed failed to align the scans before merging.

An objective (and honest) person would have stated that fact instead
of trying to hide his shortcomings by intentional misdirection.

Just being objective

Oh well, if you're gonna be like that... ;o)

Don.

 

[Don]

But I made no reference to scanner software. In the cases where I've
used long exposure, it has mostly been with Silverfast because they've
had HDR tools for while. And some scanners do exhibit more blooming than
others.

That is all true, but as explained, blooming is not the issue. One of
the two key aspects of HDR is exactly to *eliminate* blooming!!!

The key issue is misaligned scans. You can easily test that. Create a
duplicate of an image and sub-pixel shift it (or even shift it by a
full pixel in any direction!). Now merge the two as you would an HDR
image and you will have noticed what Bart and Ed call "blooming". That
is *not* blooming! It's simply two misaligned scans!

The "professional" Ed and "knowledgeable" Bart should know that. So,
either they don't (which seems improbable, but not impossible) or are
being intentionally misleading (which, judging by history, seems a
more plausible explanation).

Its not uncommon in my photos to have highlights, esp specular, surround
by midtaones and darker detail. The point I was making was that blooming
affects adjadcent sensor area, skewing them in way that often not easily
correctable.

It is if - as explained - you set up a proper series before an HDR
merge. Again:

One of the two key aspects of HDR is exactly to *ELIMINATE* the
effects of blooming!

Even with a perfectly aligned HDR merger, the color and exposure shift
can produce artifacts like fringing or what sometimes looks like really
bad chromatic abberration. Even though the clipped highs are discarded,
the lower values are kept and that causes the problems in the merger. If
you discard values that are too low, you end up defeating the purpose of
the merger.

Its not always a problem, but it does exist.

But that's the problem of inferior software, not the procedure. Which
is why I specifically stated "reasonable HDR program". There are many
programs out there *calling* themselves HDR programs (can't speak for
SilverFast, though, because I haven't tried its HDR merge).

When done properly, an HDR program would first establish the amount of
misalignment with a process called "correlation". Following that the
scans are aligned using a process called "convolution". There are many
types each having pluses and minuses, but "bicubic" and "bilinear" are
most common. Only then are the scans merged using a process called
"tone mapping" to correct any color shifts.

In all of this the blooming areas are automatically thrown away and
don't even come close to the areas of interest.

As I said, if blooming were a problem, HDR as a concept just couldn't
work. Not only it does, but eliminating blooming is a key aspect of
HDR!!!

Don.

 

[Don]

If you scan a gradient white to gray to black stripes, at the border
between the blown out whites and gray, you may see fringing/color shifting

Yes, but my point was that even in that most extreme case there is a
sufficient amount of data to blend into an HDR image seamlessly. Of
course, when done properly and using reliable software.

It doesn't happen always, and some sensors are worse than others. Also,
some CCD's can tolerate more exposure than others before blooming. Its
also color dependent. I've noticed that blooming tends to occurs more
with yellows and reds than blues and greens.

Blooming is a totally separate issue. It's just not relevant to HDR
because all of that is thrown away. One of the two key aspects of HDR
is to *eliminate* blooming!!!

Yes. Happens all the time with specular highlights.

In that case you're either using an bad program or are not operating
it correctly.

Blooming just can't occur in a properly generated HDR image because
that data is *thrown away*! That's what HDR does! It *eliminates*
blooming!!!

But what happens when the adjacent pixels areas that are affected by the
color shift carry the very detail you are trying to preserve?

You get it from the next/previous image in the series where the area
you want to preserve is properly exposed. That's the whole point of
HDR!

Don.

 

[UrbanVoyeur]

Blooming is a totally separate issue. It's just not relevant to HDR
because all of that is thrown away. One of the two key aspects of HDR
is to *eliminate* blooming!!!




In that case you're either using an bad program or are not operating
it correctly.

Blooming just can't occur in a properly generated HDR image because
that data is *thrown away*! That's what HDR does! It *eliminates*
blooming!!!

Not quite. HDR merges several exposures so that areas that contain no
detail are discarded. It does not directly deal with blooming, though it
will discard the very over exposed areas that led to the blooming in
adjacent areas.

Note: Blooming is not just pushing adjacent areas to clipping. It can
color shift them without overexposure. This can lead to fringing and odd
color aberrations.

You get it from the next/previous image in the series where the area
you want to preserve is properly exposed. That's the whole point of
HDR!

You missed my point, probably because I used the term "preserve"

What I was trying to say was:

Blooming can affect the very areas you are trying to bring out with long
exposure. It can color shift and weirdly expose dark areas with detail
that are adjacent to the blown or specular highlights. These areas are
often ones in which I would try to restore detail to with the long exposure.

Those dark and low midtone areas have no little or no detail in the
other exposures. If fact the detail may show up only in the scan that so
overexposes the highlights that it blooms. So going back to the lower
scan exposures for these areas doesn't help.

Nor does changing the merge threshold, as these values are not shifted
into "high" range. What you see more often then dramatic exposure shifts
is color shifts - which are difficult to correct.

It is possible that you have not encountered these conditions.

 

[UrbanVoyeur]

But that's the problem of inferior software, not the procedure. Which
is why I specifically stated "reasonable HDR program". There are many
programs out there *calling* themselves HDR programs (can't speak for
SilverFast, though, because I haven't tried its HDR merge).

When done properly, an HDR program would first establish the amount of
misalignment with a process called "correlation". Following that the
scans are aligned using a process called "convolution". There are many
types each having pluses and minuses, but "bicubic" and "bilinear" are
most common. Only then are the scans merged using a process called
"tone mapping" to correct any color shifts.

In all of this the blooming areas are automatically thrown away and
don't even come close to the areas of interest.

As I said, if blooming were a problem, HDR as a concept just couldn't
work. Not only it does, but eliminating blooming is a key aspect of
HDR!!!

Don, I understand what you are saying about alignment being important.

However, alignment has not been much of an issue for me with Silverfast.
Dealing with the more subtle effects of blooming has been.

 

[Bruce Gaylinn]

Yes, but my point was that even in that most extreme case there is a
sufficient amount of data to blend into an HDR image seamlessly. Of
course, when done properly and using reliable software.




Blooming is a totally separate issue. It's just not relevant to HDR
because all of that is thrown away. One of the two key aspects of HDR
is to *eliminate* blooming!!!




In that case you're either using an bad program or are not operating
it correctly.

Blooming just can't occur in a properly generated HDR image because
that data is *thrown away*! That's what HDR does! It *eliminates*
blooming!!!




You get it from the next/previous image in the series where the area
you want to preserve is properly exposed. That's the whole point of
HDR!

Don.

Don,

As I understand it, you are talking about new, complex, state of the art
High Dynamic Range techniques involving merging data from a controlled
series of scans that is stored in new non-standard image formats. But
the original poster asked about problems with a simple "long exposure
pass" which Viewscan will allow you to push to the point where blooming
can become a problem (kindly explained to him by Viewscan author Ed).
Bart suggested that he could increase his dynamic range by merging 2
scans but that blooming could still be a problem. You have come back
saying that Ed and Bart are lying to him to hide bugs in Viewscan and
that blooming is not the problem. Well the latest HDR methods may allow
you to avoid much of the blooming problem, but few people have the
luxury to be working with this bleeding edge technology and for what the
poster is actually doing Ed and Bart have tried to steer him right.

Sorry Don. I came into reading this group to learn how to make the most
of my new scanner. I have never tried Viewscan and have no stake in any
of this, but after a few months of your constant unprovoked and
inaccurate attacks on Viewscan and anyone who points out your
distortions it really gets annoying. Newbies who have not followed your
tirades might actually believe you. Clearly Viewscan is not perfect,
has bugs and doesn’t support every function on every scanner (especially
functions the scanner hardware was never intended to support). Such is
reality. But it offers some features and hardware support unavailable
else ware and for its user base it generally offers good functionality,
flexibility and value (don't attack me for supporting something I don't
personally use, you don't use it either). I know you want to strive for
perfection, but that does not give you the right to attack experienced
users offering honest, practical advice and call them liars as if there
were some giant Viewscan conspiracy. Why don't you attack Microsoft.
Their software is even buggier, and they actually are trying to take
over the world.

Bruce

 

[Don]

Don, I understand what you are saying about alignment being important.

No, you don't because...

However, alignment has not been much of an issue for me with Silverfast.
Dealing with the more subtle effects of blooming has been.

.... what you call "blooming" is primarily the result of *misalignment*
(and secondarily the result of failure to tone map).

Technically, what you see is *ghosting*, not blooming.

Question:

Does HDR *concept* remove blooming?

Yes or no? Absolute question, no qualifications.

Don.

 

[Don]

Not quite. HDR merges several exposures so that areas that contain no
detail are discarded. It does not directly deal with blooming, though it
will discard the very over exposed areas that led to the blooming in
adjacent areas.

That shows that you do not understand the most basic concept of HDR:

Blooming is just *not* possible in HDR!

Period. No ifs and buts. Case closed. The fat lady has sung...

The whole point of HDR is exactly to *eliminate* blooming in
highlights (and noise in the shadows).

Until you grasp that, the rest is really futile.

Note: Blooming is not just pushing adjacent areas to clipping. It can
color shift them without overexposure. This can lead to fringing and odd
color aberrations.

Does not make one iota of difference.

HDR *throws all that away*!

You missed my point, probably because I used the term "preserve"

No, you missed my point because you can't have it both ways.

If the adjacent pixels are improperly exposed and are corrupt (for
whatever reason: clipping, blooming, whatever...) they are not worth
preserving (and HDR throws them away).

If the adjacent pixels are properly exposed they are worth preserving
(and HDR preserves them).

What I was trying to say was:

Blooming can affect the very areas you are trying to bring out with long
exposure. It can color shift and weirdly expose dark areas with detail
that are adjacent to the blown or specular highlights. These areas are
often ones in which I would try to restore detail to with the long exposure.

That shows, again, that you don't really understand HDR.

That color shift is addressed by *tone mapping*.

Pulling detail out of border areas is addressed by proper exposure for
those areas.

Those dark and low midtone areas have no little or no detail in the
other exposures. If fact the detail may show up only in the scan that so
overexposes the highlights that it blooms. So going back to the lower
scan exposures for these areas doesn't help.

That doesn't make any sense...

If the desired detail only occurs in one exposure but it's corrupt
(for whatever reason) that means you need to ***add exposures*** to
your series!

Once again, that shows you don't really understand how HDR works.

Nor does changing the merge threshold, as these values are not shifted
into "high" range. What you see more often then dramatic exposure shifts
is color shifts - which are difficult to correct.

So, you make a proper exposure for the area you want!

That flexibility is the beauty of HDR. Nothing is beyond its reach!

You somehow seem to think you're locked into a predetermined set of
exposures. You are *not*!

If the series does not properly expose an area you're interested in,
*increase the series*! Go to half a stop, go to quarter of a stop, go
to 1/1,000,000th of a stop... That's the whole point of HDR!

!!!===> If you want, you can - in theory - have a different exposure
for every pixel! <===!!!

It is possible that you have not encountered these conditions.

After close to 3 years of wrestling with high contrast Kodachromes
I've experienced *every* condition! Believe me!!!

And I have scratchmarks on the walls (from climbing) to prove it! ;o)

Don.

 

[Don]

As I understand it, you are talking about new, complex, state of the art
High Dynamic Range techniques involving merging data from a controlled
series of scans that is stored in new non-standard image formats.

You don't need to know anything about that to benefit from it. Even an
absolute beginner can use a program like HDR Shop which will do most
of that automatically. And on top of that, it's free!

Actually, the concept is quite old. Indeed, I myself "invented" a
similar procedure until I learned it has already been done. It's a
very elementary concept which - sooner or later - occurs to everyone
who's faced with limited dynamic range.

The resulting images do not have to be stored in a non-standard
format. If (like me) all you want to do is remove noise from shadows
but avoid clipping the highlights, you can store the target image in a
regular 16-bit TIF (which is what I do).

Simply consider that 32-bit floating point version only as an
intermediary stage where you know that every portion of the image has
been properly exposed without any distortion (clipping or noise). You
can then reduce the dynamic range to 16-bit with no significant loss.

After all your monitor is only 8-bit as are your eyes, so 16-bit is
more than enough. I archive that 16-bit image and then out of that I
edit an 8-bit version for consumption (in my case, for viewing on a
monitor).

But
the original poster asked about problems with a simple "long exposure
pass" which Viewscan will allow you to push to the point where blooming
can become a problem (kindly explained to him by Viewscan author Ed).

That's the problem! What he calls "blooming" is actually *ghosting*.

I object to that mischaracterization used to try and hide the fact
that "long exposure pass" is totally inadequate because it fails to
align the images (among other things).

I have been using "twin scans" (as I called them) on my LS-30 (10-bits
internal, 8-bits external) and even there, there was *no* blooming
when done properly!!! And that's with high-contrast Kodachromes!

So, blooming is simply *not* the issue. It's a straw man used to
divert attention from the real problem, which is failure of VueScan to
align images before merging, failure to tone map and failure to
combine images instead of uncontrolled blending! Those are facts!

If there is *real* blooming in the resulting image that means that the
software is inadequate. Whether it's VueScan or "SuperDuperScan" or
whatever... makes no difference! The problem is usually because the
images are *blended* rather than combined, which is what VueScan does
resulting in vastly inferior results.

If the images are combined with a hard edge (highlights scan
contributes *only* the highlights, shadows scan contributes *only* the
shadows) there is absolutely no problem. However, that exposes another
catch i.e. a color shift due to different exposures. This is handled
by "tone mapping".

Inferior, amateur programs like VueScan *don't do that* (!), so trying
to *hide* this color mismatch, they *blend* the two images with a high
feather value! Combined with *misalignment* that creates an awful mess
(ghosting) in that feathered border area... That has *nothing* to do
with blooming!

And then to justify this mess the author (and Bart) blame "blooming"
even though it has absolutely nothing to do with the mess, as (I hope)
I've again explained!

Bart suggested that he could increase his dynamic range by merging 2
scans but that blooming could still be a problem. You have come back
saying that Ed and Bart are lying to him to hide bugs in Viewscan and
that blooming is not the problem. Well the latest HDR methods may allow
you to avoid much of the blooming problem, but few people have the
luxury to be working with this bleeding edge technology and for what the
poster is actually doing Ed and Bart have tried to steer him right.

Actually, they have not. They have given him a *false* "reason" why it
didn't work, when quite clearly the real, main reason for the problem
is that the images were not aligned (as well as not color corrected).

As I already mentioned, if:

1. The two images are aligned.
2. Discoloration in the shadows scan is corrected.
3. The images are combined with a hard edge (*not* blended).

Then there is no problem and blooming does not even enter into it!

And we're not talking "cutting edge HDR" but a simple twin scan. CCD
blooming is simply not the issue!

!!!
Take the same two images which VueScan can't blend and feed them to
HDR Shop. *No* "blooming"!!! So, clearly it's a VueScan problem.
That's just an objective fact!
!!!

Sorry Don. I came into reading this group to learn how to make the most
of my new scanner. I have never tried Viewscan and have no stake in any
of this, but after a few months of your constant unprovoked and
inaccurate attacks on Viewscan and anyone who points out your
distortions it really gets annoying.

I'm sorry but that mischaracterization is vastly inaccurate and
without any basis in fact. Could you please point to a *single*
occurance of "inaccurate attacks" (*in context*)? Everything I wrote
is based on facts. I urge you to go back and re-read the messages
carefully (and in context).

!===> In this case, I also provided a link to HDR Shop which even
absolute beginners can use!

Now, what is more useful to you: That link or an *inaccurate* excuse?

I'm sorry, but you're just not being objective.

I know you want to strive for
perfection, but that does not give you the right to attack experienced
users offering honest, practical advice and call them liars as if there
were some giant Viewscan conspiracy.

That's where you're just patently wrong. It is the VueScan "fans" that
have repeatedly attacked me (including abuse) and I have *never*
responded in kind! All I do is simply state objective facts.

What's more, they seem obsessed with these attacks instead of trying
to help! You don't need to look hard to find numerous examples where
instead of addressing the question all they cared for is making
personal slander attacks.

If you read carefully you'll notice I do *not* respond in kind
limiting my messages to objective facts.

So, you mischaracterization is simply factually wrong.

Why don't you attack Microsoft.
Their software is even buggier, and they actually are trying to take
over the world.

Many reasons...

I don't see "microsoft" in the newsgroup name.
I *do* attack Microsoft.
What does that have to do with the subject at hand?
Etc.

Don.