| Author |
Message |
cubilcle281
Guest
|
 Posted:
Mon Oct 17, 2005 6:12 am Post subject:
Sprintscan 35+, 10 bits vs 8 bits |
|
|
Hi all,
I am scanning slides with a Polaroid Sprintscan 35+. They are old
Instamatic slides (126 film) which are ~26mm square, and while the
slide will fit into most modern scanners, the top or sides get chopped
off. So for this batch of slides (and for budget reasons for now), I
am stuck with this particular scanner.
I have a lot of slides to do, so I am trying to get through it in the
fastest way possible, but also allow me to get the best possible
quality. With any other scanner, this would be easy - scan raw and
correct later. However, the Sprintscan does 10 bits/channel
internally, converting to 8 bits/channel for output, so you really have
to correct the slides as you scan them.
Or so I thought! After setting levels for a slide I loaded the file
into Photoshop elements, and looked at the histogram. There was
distinct banding! This gives me the impression that the levels
correction is being done on the 8-bit output, rather than the 10-bits
internally that I had thought.
Can anyone confirm what is going on here? What options in polacolor
are done on the internal 10-bit scan? I have heard 'gamma' mentioned
before, but what does that mean in relation to levels and curves? If
all the levels processing is done on the 8-bit output, then I would
rather work in Photoshop, but I would like to make use of the 10-bit
scan if it is at all possible.
One last thought; it is possible that the 10-bit->8-bit conversion is
only really used when doing negative scans, since the dynamic range is
so much less.
Thanks in advance,
C |
|
| Back to top |
|
 |
Don
Guest
|
| Posted:
Mon Oct 17, 2005 5:14 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On 16 Oct 2005 18:12:20 -0700, "cubilcle281"
<cubicle281@mailinator.com> wrote:
| Quote: | Or so I thought! After setting levels for a slide I loaded the file
into Photoshop elements, and looked at the histogram. There was
distinct banding! This gives me the impression that the levels
correction is being done on the 8-bit output, rather than the 10-bits
internally that I had thought.
Can anyone confirm what is going on here? What options in polacolor
are done on the internal 10-bit scan? I have heard 'gamma' mentioned
before, but what does that mean in relation to levels and curves? If
all the levels processing is done on the 8-bit output, then I would
rather work in Photoshop, but I would like to make use of the 10-bit
scan if it is at all possible.
|
I'm not familiar with Polaroid Sprintscan but a couple of things...
Gamma is a way to "brighten" the image without "clipping". Too
complicated to explain in detail but essentially a curve is applied to
the raw data. This is what causes the gaps in the histogram because
the area on the left is stretched while the area on the right is
compressed. Imagine the middle point dragged to the right. The extreme
points at both ends remain as they are so that's why there's no
clipping.
You may also notice "recursive waves" but that occurs when histogram
is converted from 10 to 8 bits for display.
One thing you may try is to set gamma to 1.0. That's also known as
"linear gamma". If you then turn off all the other editing features,
or set them to neutral settings, you should get a fairly smooth
histogram. Of course, that will not get you the 10-bit accuracy, but
at least the scanner software will not do any more "damage".
One option is to then open such a file in Photoshop and as the very
first step convert to 16-bit. The image will look very dark, but
that's because it's in gamma 1.0. Next, go to Levels and change the
middle point value from 1.0 to 2.2. That's the quick way. A more
complicated way is to get gamma curves from someplace and use them
e.g. http://www.aim-dtp.net/aim/download/gamma_maps.zip.
Do your edits on that. Of course, this will not recover the original
10-bits, but at least you will do all your edits in 16-bits which will
give you more elbow room.
| Quote: | One last thought; it is possible that the 10-bit->8-bit conversion is
only really used when doing negative scans, since the dynamic range is
so much less.
|
It's possible, but not probable. If what comes off the CCDs is 10 bits
then it wouldn't make sense to just process that regardless of the
media. But you never know...
Don. |
|
| Back to top |
|
|
mp
Guest
|
| Posted:
Tue Oct 18, 2005 3:11 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
Hmm,
It's not clear to me where your problems are originating, but let me
clear up a few details.
CCD captures analog and turns it into voltage. The a/d converter is
the thing converting analog voltage into discreet bytes.
The A/D converter makes 8 + 2 bytes. Not really "10" but they use the
2 bytes for accuracy I beleive. So, it's pretty much always 8
bytes/channel.
Scan raw and adjust later:
Why can't you do that with the Polaroid? Did you check the scanner for
accuracy before starting? Are you letting it warm up?
Setting levels for a slide:
If you are adjusting levels and then checking the histogram and finding
banding, photoshop is making your "banding problem."
I'm all for intelligent questions, but you are blaming a decent scanner
for some problems that most likely have little to do with the
hardware/software.
Please provide your scanning software setting please. |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Tue Oct 18, 2005 5:28 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
mp wrote:
| Quote: | Hmm,
It's not clear to me where your problems are originating, but let me
clear up a few details.
CCD captures analog and turns it into voltage. The a/d converter is
the thing converting analog voltage into discreet bytes.
The A/D converter makes 8 + 2 bytes. Not really "10" but they use the
2 bytes for accuracy I beleive. So, it's pretty much always 8
bytes/channel.
|
That's *bit* actually, not byte, a byte being made up of 8 bits.
Unless that particular scanner does something very strange, 10 bits are
10 bits -- yeah, the least significant two bits are used for "accuracy",
but so are the other eight!
Now, many scanners used to (and maybe still do) offer only 8 bits per
channel "externally" (i.e. either on the bus, or from the propertary
Twain driver), while working with more than that "internally" (i.e.
inside the scanner, or inside the Twain driver).
This, apparenly, is the OP's case. However, he said that the results
"look like" (the histograms look like) only 8 bpc were used even
internally during gamma correction.
This sounds definitely strange (either it's a 10-bit scanner *somehow*,
or it isn't, after all).
Though, I have a feeling that the scanner *is* 10-bit, only the OP had
some excessively high expectation over the results one can obtain from
10 bpc: I think that, with only 10 bpc, moderate gamma correction will
quite possibly result in histogram "banding".
Most scanners now offer 16-bit scanning (i.e. they have a 16-bit A/D,
though you won't find any scanner where all the 16 bits contain
meaningful values instead of noise).
| Quote: | Scan raw and adjust later:
Why can't you do that with the Polaroid? Did you check the scanner for
accuracy before starting? Are you letting it warm up?
|
If you have a scanner with an internal bit depth higher than the
external bit depth, it's completely normal not to be able to "scan raw
and adjust later".
I mean, of course you *can* do it, but the quality is going to suffer
compared to adjusting at scantime.
Really, scanners with internal/external bit depth differences are just
stupid. I'd suggest trying SANE on Linux (though there might be a decent
build for Windows somewhere) on those scanner, as AFAIK, some/many of
those scanners really "cripple" bit depth inside the *Twain driver*, not
really the scanner itself.
| Quote: | Setting levels for a slide:
If you are adjusting levels and then checking the histogram and finding
banding, photoshop is making your "banding problem."
|
He said he's adjusting levels at scan time (which should, in theory, be
done on a 10-bpc image), not inside Photoshop.
| Quote: | I'm all for intelligent questions, but you are blaming a decent scanner
for some problems that most likely have little to do with the
hardware/software.
|
I'm not sure.
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
cubilcle281
Guest
|
| Posted:
Tue Oct 18, 2005 5:51 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
| Quote: | From what I have gathered reading over historical posts in google
groups, the scanner does 10 bits internally, but only outputs (as in, |
leaves the scanner) 8-bit. IIRC, Ed Hamrick wasn't even able to get
more than 8 bits out of the scanner. There was some reference to him
being able to modify the gamma, and gamma correction is done in the
10-bit space. I looked into this a long time ago so I can't find any
references, but it all sounds plausible.
I should explain that I am trying to scan a couple of hundred slides,
so I am trying to avoid having to correct each one as I go if it turns
out I can do it later in photoshop (much faster!) with no loss of
quality. Plus, I then have my digital 'archive' and I can choose to
correct only what I want/need at the time and leave the rest for later.
Therefore, what I really want to know is what is done in the 8-bit
space vs what is done in 10-bit, so I can make the best use of my time.
I have not seen any actual banding in the image, rather just banding in
the histogram. It is not a problem in itself, but just an indication
that things may be done in 8-bit.
To help me sort this out, does anyone know of a program that can
analyse a tiff file and show the intensity values - like a histogram
but in more detail ??
Thanks
Lorenzo J. Lucchini wrote:
| Quote: | mp wrote:
Hmm,
It's not clear to me where your problems are originating, but let me
clear up a few details.
CCD captures analog and turns it into voltage. The a/d converter is
the thing converting analog voltage into discreet bytes.
The A/D converter makes 8 + 2 bytes. Not really "10" but they use the
2 bytes for accuracy I beleive. So, it's pretty much always 8
bytes/channel.
That's *bit* actually, not byte, a byte being made up of 8 bits.
Unless that particular scanner does something very strange, 10 bits are
10 bits -- yeah, the least significant two bits are used for "accuracy",
but so are the other eight!
Now, many scanners used to (and maybe still do) offer only 8 bits per
channel "externally" (i.e. either on the bus, or from the propertary
Twain driver), while working with more than that "internally" (i.e.
inside the scanner, or inside the Twain driver).
This, apparenly, is the OP's case. However, he said that the results
"look like" (the histograms look like) only 8 bpc were used even
internally during gamma correction.
This sounds definitely strange (either it's a 10-bit scanner *somehow*,
or it isn't, after all).
Though, I have a feeling that the scanner *is* 10-bit, only the OP had
some excessively high expectation over the results one can obtain from
10 bpc: I think that, with only 10 bpc, moderate gamma correction will
quite possibly result in histogram "banding".
Most scanners now offer 16-bit scanning (i.e. they have a 16-bit A/D,
though you won't find any scanner where all the 16 bits contain
meaningful values instead of noise).
Scan raw and adjust later:
Why can't you do that with the Polaroid? Did you check the scanner for
accuracy before starting? Are you letting it warm up?
If you have a scanner with an internal bit depth higher than the
external bit depth, it's completely normal not to be able to "scan raw
and adjust later".
I mean, of course you *can* do it, but the quality is going to suffer
compared to adjusting at scantime.
Really, scanners with internal/external bit depth differences are just
stupid. I'd suggest trying SANE on Linux (though there might be a decent
build for Windows somewhere) on those scanner, as AFAIK, some/many of
those scanners really "cripple" bit depth inside the *Twain driver*, not
really the scanner itself.
Setting levels for a slide:
If you are adjusting levels and then checking the histogram and finding
banding, photoshop is making your "banding problem."
He said he's adjusting levels at scan time (which should, in theory, be
done on a 10-bpc image), not inside Photoshop.
I'm all for intelligent questions, but you are blaming a decent scanner
for some problems that most likely have little to do with the
hardware/software.
I'm not sure.
[snip]
by LjL
ljlbox@tiscali.it |
|
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Tue Oct 18, 2005 6:09 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
cubilcle281 wrote:
| Quote: | From what I have gathered reading over historical posts in google
groups, the scanner does 10 bits internally, but only outputs (as in,
leaves the scanner) 8-bit. IIRC, Ed Hamrick wasn't even able to get
more than 8 bits out of the scanner. There was some reference to him
being able to modify the gamma, and gamma correction is done in the
10-bit space. I looked into this a long time ago so I can't find any
references, but it all sounds plausible.
|
I see. Well, in this case I suppose you have no choice but to live with
8-bit external.
| Quote: | I should explain that I am trying to scan a couple of hundred slides,
so I am trying to avoid having to correct each one as I go if it turns
out I can do it later in photoshop (much faster!) with no loss of
quality. Plus, I then have my digital 'archive' and I can choose to
correct only what I want/need at the time and leave the rest for later.
Therefore, what I really want to know is what is done in the 8-bit
space vs what is done in 10-bit, so I can make the best use of my time.
|
Why don't you
1) scan image1 at linear gamma
2) correct image1 in Photoshop to gamma 2.5
3) scan image2 at gamma 2.5
4) compare image1 and image2
Step 4 could probably be done in various ways, the most obvious of which
(to me) would be to compare the histograms.
| Quote: | I have not seen any actual banding in the image, rather just banding in
the histogram. It is not a problem in itself, but just an indication
that things may be done in 8-bit.
|
As I said, you're right saying *may*.
10-bit is not that much: I think banding could easily arise in the most
significant 8 bits from gamma-correcting a 10-bit image.
I think you should try this as well:
1) scan at gamma 1.1
2) check if there is *any* banding in the histogram
| Quote: | To help me sort this out, does anyone know of a program that can
analyse a tiff file and show the intensity values - like a histogram
but in more detail ??
|
ImageMagick's "identify", or the equivalent NetPBM tool I can't remember
the name of -- pnmhist I'd think.
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Tue Oct 18, 2005 9:16 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On 17 Oct 2005 17:51:43 -0700, "cubilcle281"
<cubicle281@mailinator.com> wrote:
| Quote: | I should explain that I am trying to scan a couple of hundred slides,
so I am trying to avoid having to correct each one as I go if it turns
out I can do it later in photoshop (much faster!) with no loss of
quality. Plus, I then have my digital 'archive' and I can choose to
correct only what I want/need at the time and leave the rest for later.
Therefore, what I really want to know is what is done in the 8-bit
space vs what is done in 10-bit, so I can make the best use of my time.
|
Time is of course, important, as is bit depth. However, one other
thing to consider is how good are those edits in a scanner program?
I mean, you are working through the preview "keyhole" rather than the
full Photoshop display with up to 1600% magnification. This means,
that some of those inexact edit decisions made based on the limited
scanner program features may cancel out any advantages of it
(perhaps?) working in 10 bits.
| Quote: | I have not seen any actual banding in the image, rather just banding in
the histogram. It is not a problem in itself, but just an indication
that things may be done in 8-bit.
|
Some histogram artefacts are actually introduced by the display
algorithm. Even Photoshop suffers from that. Case in point are the
"waves" I referred to in my last message.
To be really sure you need a histogram which goes beyond 8-bit. That's
why I wrote my own true 16-bit histogram.
| Quote: | To help me sort this out, does anyone know of a program that can
analyse a tiff file and show the intensity values - like a histogram
but in more detail ??
|
Before I wrote the above mentioned stand-alone histogram program, I
used this free Photoshop plug-in:
http://www.reindeergraphics.com/free.shtml
However, that one only goes up to 12-bits.
The thing is, it won't do you much good if the data you're looking at
is only 8-bits. I guess what you really want is your scanner program's
histogram to display more than 8-bits, before the file is exported. A
bit of a Catch 22. :-(
Don. |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Wed Oct 19, 2005 12:04 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
Don wrote:
| Quote: | On 17 Oct 2005 17:51:43 -0700, "cubilcle281"
cubicle281@mailinator.com> wrote:
I should explain that I am trying to scan a couple of hundred slides,
so I am trying to avoid having to correct each one as I go if it turns
out I can do it later in photoshop (much faster!) with no loss of
quality. Plus, I then have my digital 'archive' and I can choose to
correct only what I want/need at the time and leave the rest for later.
Therefore, what I really want to know is what is done in the 8-bit
space vs what is done in 10-bit, so I can make the best use of my time.
Time is of course, important, as is bit depth. However, one other
thing to consider is how good are those edits in a scanner program?
I mean, you are working through the preview "keyhole" rather than the
full Photoshop display with up to 1600% magnification. This means,
that some of those inexact edit decisions made based on the limited
scanner program features may cancel out any advantages of it
(perhaps?) working in 10 bits.
|
I would suggest this: scan raw, then do the adjustments in Photoshop
*and take note of the adjustments that have been made*, then scan again
using the same adjustments that were applied in Photoshop.
No doubt that this does take time; however, perhaps by scanning at a
lower resolution in the "preview" scans, and through some smart "batch
workline", a reasonable compromise might be obtained.
| Quote: | [snip]
The thing is, it won't do you much good if the data you're looking at
is only 8-bits. I guess what you really want is your scanner program's
histogram to display more than 8-bits, before the file is exported. A
bit of a Catch 22. :-(
|
Yeah.
But in any case (though I know that here we'll go again...), I think
that doing adjustments at scan time still has an advantage -- that is,
if the scanner really does scan at 10-bit.
For example, setting the whitepoint and blackpoint at scantime should do
no damage and can improve the results, if the scanned image doesn't
cover the whole range of values.
Note that you *can't* precisely know the exact values for the whitepoint
and the blackpoint from a low-resolution preview, so you should either
take some safety margin, or be prepared to scan again (some
trial-and-error, which could be made automatic, though) in case of clipping.
I think adjusting gamma could be a little more problematic, without
seeing a full-size preview first. Still, I think it can be done safely
with many images.
More sophisticated adjustments are left as an exercise to the reader,
who will surely find many very dangerous caveats, at least if his name
is Don :-)
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
mp
Guest
|
| Posted:
Wed Oct 19, 2005 2:17 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
| Quote: | But in any case (though I know that here we'll go again...), I think
that doing adjustments at scan time still has an advantage
|
You are right it has huge advantages. IMHO, it's the best way to
capture the most data.
| Quote: | you are working through the preview "keyhole" rather than the
full Photoshop display with up to 1600% magnification
Long ago, there was some truth to this. With good scanning software, |
the display is color managed just like Photoshop. Even the cheap
Canon 4200F software manages the display.
The ideal scanner workflow is to color correct in the scanning software
to get things close, then finish in your image editor. Odds are
excellent you will end up with more data to send to the printer. |
|
| Back to top |
|
|
Wilfred
Guest
|
| Posted:
Wed Oct 19, 2005 7:26 am Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
Lorenzo J. Lucchini wrote:
| Quote: | cubilcle281 wrote:
To help me sort this out, does anyone know of a program that can
analyse a tiff file and show the intensity values - like a histogram
but in more detail ??
ImageMagick's "identify", or the equivalent NetPBM tool I can't remember
the name of -- pnmhist I'd think.
|
If you have Photoshop, or other software that can work with PS plugins,
you could also try the Wide Histogram plugin from Reindeer Graphics.
It's free: http://www.reindeergraphics.com/free.shtml#widehisto
--
Wilfred van der Vegte.
e-mail: first five letters of my first name at gmx dot net |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Wed Oct 19, 2005 5:34 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On Tue, 18 Oct 2005 21:04:35 +0200, "Lorenzo J. Lucchini"
<ljl@tiscali.it> wrote:
| Quote: | I mean, you are working through the preview "keyhole" rather than the
full Photoshop display with up to 1600% magnification. This means,
that some of those inexact edit decisions made based on the limited
scanner program features may cancel out any advantages of it
(perhaps?) working in 10 bits.
I would suggest this: scan raw, then do the adjustments in Photoshop
*and take note of the adjustments that have been made*, then scan again
using the same adjustments that were applied in Photoshop.
No doubt that this does take time
|
That's one way. But, as you say, it's time consuming and he said he
wanted to speed things up.
| Quote: | But in any case (though I know that here we'll go again...), I think
that doing adjustments at scan time still has an advantage -- that is,
if the scanner really does scan at 10-bit.
|
That's a big if and - unless he goes through the above procedure - his
editing decisions will be made based on the preview keyhole i.e. they
will be wrong.
| Quote: | For example, setting the whitepoint and blackpoint at scantime should do
no damage and can improve the results, if the scanned image doesn't
cover the whole range of values.
|
No, it doesn't, simply because you're basing those crucial decisions
on the *preview image* histogram!
Again, that histogram is based on the *tiny* preview image! Not only
that, but most likely the preview was done in *8-bit*! (BTW, NikonScan
previews at 16-bit.)
| Quote: | I think adjusting gamma could be a little more problematic, without
seeing a full-size preview first. Still, I think it can be done safely
with many images.
|
Actually, gamma is about the only thing you can do safely in scanning
software. The setting is known and fixed at 2.2 (or 1.8 for Macians).
| Quote: | More sophisticated adjustments are left as an exercise to the reader,
who will surely find many very dangerous caveats, at least if his name
is Don :-)
|
Just the facts! :o)
The root problem, Lorenzo, is that no matter how hard you try - and
you do try very hard! ;o) - you just can't get around the fact that
applying changes at scan time is a bad idea in all but most trivial of
cases.
Doing that means basing major editing decisions on the preview keyhole
and that will never be as good as working on the full image. Not to
mention all the other problems (enumerated earlier) associated with
scanning software editing.
Don. |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Wed Oct 19, 2005 5:34 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On 18 Oct 2005 14:17:27 -0700, "mp" <mpapet@gmail.com> wrote:
| Quote: | you are working through the preview "keyhole" rather than the
full Photoshop display with up to 1600% magnification
Long ago, there was some truth to this. With good scanning software,
the display is color managed just like Photoshop. Even the cheap
Canon 4200F software manages the display.
|
You're missing the key point. It's not about color management.
That scanning software histogram is of a *tiny* preview image! What's
more many scanning program do this preview in *8-bit* for speed! So,
you'll be basic major editing decisions on guesswork.
| Quote: | The ideal scanner workflow is to color correct in the scanning software
to get things close, then finish in your image editor. Odds are
excellent you will end up with more data to send to the printer.
|
No, actually doing color correction at scanning stage is about the
*worst* thing you can do! You may get away with setting the black and
white point sometimes... maybe... if you're very conservative with
clipping... But color correcting in scanner software is *very*
destructive and inexact!
The ideal procedure is to scan raw at maximum magnification and
bit-depth (optionally in linear gamma) and then do all editing in
external software.
After all, scanning software was written to scan, not to edit. That's
what external editors are for.
Don. |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Wed Oct 19, 2005 6:27 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
Don wrote:
| Quote: | On Tue, 18 Oct 2005 21:04:35 +0200, "Lorenzo J. Lucchini"
ljl@tiscali.it> wrote:
[snip]
But in any case (though I know that here we'll go again...), I think
that doing adjustments at scan time still has an advantage -- that is,
if the scanner really does scan at 10-bit.
That's a big if
|
Yes, but I think this can be found out with a bit of testing: I
described some ideas for doing it in another article.
| Quote: | and - unless he goes through the above procedure - his
editing decisions will be made based on the preview keyhole i.e. they
will be wrong.
|
Where do you place the line that separates a scan from a "keyhole"?
A preview doesn't necessarily have to be made at 100dpi or so.
Now, no matter how high your preview's resolution, you won't have *all*
the necessary information until you take your preview at the *same*
resolution as the final scan; however, with a decent compromise between
resolution and scanning speed, I think you can come pretty darn close.
| Quote: | For example, setting the whitepoint and blackpoint at scantime should do
no damage and can improve the results, if the scanned image doesn't
cover the whole range of values.
No, it doesn't, simply because you're basing those crucial decisions
on the *preview image* histogram!
Again, that histogram is based on the *tiny* preview image!
|
Yes, but all you need from that histogram is the whitepoint and the
blackpoint.
Those *will not* be correct in the smaller preview, agreed.
But this error will result in two possible situations: either you end up
with a clipped image, or you end up with an image where the whitepoint
and blackpoint are not as "stretched" as they could have been (ideally,
1 and 254).
In the latter case, oh well, you can't have everything, but you've still
gained something.
The former case (clipping) is a little tougher, but as I said, you can
allow some margin to avoid that.
Also, it's not a case of "hmm, wonder whether I made the right
adjustments from that tiny preview": either the image clips, or it
doesn't. If it does, scan again, and consider increasing your safety
margin next time.
| Quote: | Not only
that, but most likely the preview was done in *8-bit*! (BTW, NikonScan
previews at 16-bit.)
|
I don't see how this matters for setting whitepoint and blackpoint...
Yeah, you'll only be able to chose among 256 values rather than 65536,
but I'd be very happy if this was the only problem! Whitepoint at 253.74
instead of 254... terrible! ;-)
But as you correctly say, the big problem is the limited preview
resolution, not the bit depth -- resolution *can*, at least under
extreme conditions, give you a white/blackpoint that's off by *much*,
possibly making the scan clip; bit depth can't.
| Quote: | I think adjusting gamma could be a little more problematic, without
seeing a full-size preview first. Still, I think it can be done safely
with many images.
Actually, gamma is about the only thing you can do safely in scanning
software. The setting is known and fixed at 2.2 (or 1.8 for Macians).
|
Yes, but I wan't thinking about that, I was thinking about using gamma
to adjust the original image (not a very conventional use of gamma
perhaps, but I think it's quite a common edit).
| Quote: | More sophisticated adjustments are left as an exercise to the reader,
who will surely find many very dangerous caveats, at least if his name
is Don :-)
Just the facts! :o)
The root problem, Lorenzo, is that no matter how hard you try - and
you do try very hard! ;o) - you just can't get around the fact that
applying changes at scan time is a bad idea in all but most trivial of
cases.
|
Hmm... I can't really deny this when speaking about what I do with *my*
scanner, since *I* could scan at 16-bit, but instead prefer to scan at
8-bit and make some scan time adjustments.
In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).
But in the OP's case, he *cannot* scan at 10-bit (let alone 16-bit),
instead he *has* to work with 8-bit data.
In his case, I'd be very careful to say "just kiss goodbye to the lowest
two bits, and deal with the rest", even if the only other option is
messing with scan time settings.
After all, you don't like scantime edits, but you don't seemed to like
throwing away bits, either. It's a matter of compromise, I think -- a
compromise that, in my case, could be avoided altogether (by scanning at
16-bit), but can't in the OP's case.
Anyway, you said gamma=2.2 or gamma=1.8 is something that can safely be
done at scan time; and white/blackpoint adjustment can also be done at
scan time, though not "safely", but the worst that can happen is having
to scan again, in case of clipping.
I think these two alone are worth considering.
Also, if you have decent film curves available for the film you're
scanning, I'd throw them in, too: I think they can only help. Yeah, they
*could* cause damage if the film was developed very badly, or
something... but what the heck, just scan a test frame and decide.
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Wed Oct 19, 2005 8:16 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On Wed, 19 Oct 2005 14:34:18 +0200, Don <phoney.email@yahoo.com>
wrote:
| Quote: | So, you'll be basic major editing decisions on guesswork.
|
Correction:
So, you'll be *basing* major editing decisions on guesswork.
| Quote: | The ideal procedure is to scan raw at maximum magnification and
bit-depth (optionally in linear gamma) and then do all editing in
external software.
|
Clarification:
The ideal procedure is to scan raw at *native resolution*... etc.
Don. |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Wed Oct 19, 2005 9:24 pm Post subject:
Re: Sprintscan 35+, 10 bits vs 8 bits |
|
|
On Wed, 19 Oct 2005 15:27:07 +0200, "Lorenzo J. Lucchini"
<ljl@tiscali.it> wrote:
| Quote: | and - unless he goes through the above procedure - his
editing decisions will be made based on the preview keyhole i.e. they
will be wrong.
Where do you place the line that separates a scan from a "keyhole"?
|
Just below native resolution. Anything less than native resolution and
it's guesswork. That's the nominal answer and you can argue how much
(or little) error is there but that's not the point.
A preview isn't anywhere *near* that native resolution! In case of
preview we're talking about several orders of magnitude, not a few
pixels here and there.
| Quote: | A preview doesn't necessarily have to be made at 100dpi or so.
|
Not strictly true as most scanning programs don't even offer that
option (or at the very least limit it severely). Instead, most
scanning programs preview at what they consider "enough" resolution.
But let's assume you can set the preview to 100% i.e. native
resolution. What have you achieved with that? Nothing! You're still
stuck in the scanner program with inadequate and limited set of
editing tools.
| Quote: | Now, no matter how high your preview's resolution, you won't have *all*
the necessary information until you take your preview at the *same*
resolution as the final scan;
|
There you go! So why argue otherwise?
| Quote: | however, with a decent compromise between
resolution and scanning speed, I think you can come pretty darn close.
|
"Close only counts in grenades and horse shoes" as the saying goes.
You can come up with all sorts of convoluted procedures to make any
statement "true" but you only end up with a "cure worse than the
disease".
Since I seem stuck in a quoting mode ;o) here's one more:
"You can put lipstick on a pig, but it's still a pig!" ;o)
| Quote: | For example, setting the whitepoint and blackpoint at scantime should do
no damage and can improve the results, if the scanned image doesn't
cover the whole range of values.
No, it doesn't, simply because you're basing those crucial decisions
on the *preview image* histogram!
Again, that histogram is based on the *tiny* preview image!
Yes, but all you need from that histogram is the whitepoint and the
blackpoint.
|
Which will be only as accurate as the histogram.
The tiny preview image histogram is massively inaccurate.
Ergo: Your B&W points based on such a histogram will be equally
massively inaccurate.
| Quote: | Those *will not* be correct in the smaller preview, agreed.
|
There you go #2! Why argue otherwise when you know this?
| Quote: | But this error will result in two possible situations: either you end up
with a clipped image, or you end up with an image where the whitepoint
and blackpoint are not as "stretched" as they could have been (ideally,
1 and 254).
|
So, once again, you end up with a convoluted "solution" i.e. a cure
worse than the disease.
| Quote: | In the latter case, oh well, you can't have everything, but you've still
gained something.
|
No, you haven't! All you "gained" is having to perform multiple
previews and still end up with an inaccurate setting.
| Quote: | Also, it's not a case of "hmm, wonder whether I made the right
adjustments from that tiny preview": either the image clips, or it
doesn't. If it does, scan again, and consider increasing your safety
margin next time.
|
You're tying yourself in knots to do something which is unnecessary
just to "prove" a point which you know is wrong.
Like I said above, you end up with a convoluted "solution" only doing
even more damage. Those multiple previews ending up with a guess is a
cure worse than the disease.
| Quote: | Not only
that, but most likely the preview was done in *8-bit*! (BTW, NikonScan
previews at 16-bit.)
I don't see how this matters for setting whitepoint and blackpoint...
Yeah, you'll only be able to chose among 256 values rather than 65536,
but I'd be very happy if this was the only problem! Whitepoint at 253.74
instead of 254... terrible! ;-)
|
Yes, it is because...
| Quote: | But as you correctly say, the big problem is the limited preview
resolution, not the bit depth -- resolution *can*, at least under
extreme conditions, give you a white/blackpoint that's off by *much*,
possibly making the scan clip; bit depth can't.
|
There you go #3! So, you know all this, but still keep arguing against
it!?
All I need to do, is just sit here and you'll make all my points for
me! ;o)
| Quote: | The root problem, Lorenzo, is that no matter how hard you try - and
you do try very hard! ;o) - you just can't get around the fact that
applying changes at scan time is a bad idea in all but most trivial of
cases.
Hmm... I can't really deny this when speaking about what I do with *my*
scanner, since *I* could scan at 16-bit, but instead prefer to scan at
8-bit and make some scan time adjustments.
In this case, you're obviously right (though, you know, people make
compromises for speed, storage space and all, and I don't think mine is
so terrible a compromise if done carefully).
|
I make compromises myself all the time. That's not the point. The
point is I know I make them, and I don't try to defend them. I know
they are less then perfect and I'm OK with that because it makes sense
in the given context. It's a subjective decision and I stand by it.
But I don't pretend it's an objective decision which applies to
others. It may, if they have similar requirements, but it may not. So
I don't try to defend it as anything other than a subjective decision
within a narrowly defined context.
The problem is (and I'm talking in general terms now, not necessarily
related to this discussion) people often *want* their compromise to be
the "perfect" solution, and they tie themselves in knots trying to
justify that compromise. In other words, they themselves are very
unhappy with the compromise but instead of looking for an optimal
solution they stick with the sub-standard compromise and try to defend
the indefensible. In the end they just get into more and more trouble
as facts clearly prove otherwise.
| Quote: | But in the OP's case, he *cannot* scan at 10-bit (let alone 16-bit),
instead he *has* to work with 8-bit data.
In his case, I'd be very careful to say "just kiss goodbye to the lowest
two bits, and deal with the rest", even if the only other option is
messing with scan time settings.
|
You're missing the point! Struggling to *try* (!) and keep those two
bits (without really knowing if that attempt is successful) will
produce *worse* results than by using the alternative option where you
know what you're doing. The point is he isn't even sure if those two
bits are thrown away before scanner software applies any edits!
So, on balance, the safest option is not to risk any more damage but
get the best you can (i.e. with as little interference from the
scanner software "editing" as possible), up the bit depth afterwards
and edit in proper editing software.
Given those two options:
1. *Hope* that scanner software edits are in 10 bits and work through
the preview keyhole doing massive damage which more than cancels out
any 2-bit gain! And all along not even knowing if the 2 bits are used!
2. *Know* that externally scaled output is in true 16-bit and work
with the full complement of tools an external editor has knowing
you're getting the most out of available data.
In such a case option 2 will always produce superior results.
Don. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in