Re: NOT scanning negatives as positives

On Sat, 17 Sep 2005 18:53:56 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:

>> Oh... I though it was the "official" Epson driver. I was actually a
>> little surprised by that because even though some companies release
>> Linux drivers for their hardware most don't. Especially, for "niche"
>> markets like scanners.
>
>I really don't know how "official" to consider it.
>If you go to the Epson site (I only tried with www.epson.it), choose
>Support, select "Multifunzione" (multi-function device), "Stylus Photo
>RX500", and then "Linux", you'll find references to the Epson Kowa
>driver, at least in the FAQ.

I see, then it is an official driver.

>> OK, that could account for the lot of the "unusual" things!
>
>Most probably. When using Linux, you get used to living with the
>"unusual" :-)

Oh, I know... That's why we love Linux! ;o)

>>>Well, but have you looked at the JPEGs? Perhaps it takes some knowledge
>>>to do the fine judgements, but I can see a very clear different in noise
>>>amount -- in favor of the one with "longer exposure".
>>
>> Yes I have, but my problem is that we're dealing with two different
>> scans. So there is different data. It is possible to do some heavy
>> math which will not be affected by these small differences, but that's
>> above my head. Also, because of all the bad experiences in the past
>> when dealing with something like that I'm always afraid of some
>> "unknown" which may cause a wrong conclusion so that's why I'm so
>> careful.
>
>I realize that. But still, it's the scan made with the "weird" settings
>(custom tables and all) that looks better -- I would expect the opposite
>to happen if the scanner were doing something obscure, and not just
>taking a longer exposure.

Yes, but the stuff I look for can't be seen with the naked eye. You
need to actually analyze the data.

>> The alternative (which is what I thought was happening) is to always
>> use the same exposure and simple apply the curve afterwards. That will
>> give the illusion of changing exposure but it's all done in software.
>>
>> But the trouble with that is, why does the scan timing change!?
>
>... so consistently with exposure (also see the graph I'm pointing you
>to further below)?
>
>And, why is a scan made with a low cut-off much less noisy than one made
>with cutoff=255 and then "cutoff'ed" in software?

That's easy!

When you boost exposure (which is what a low cutoff is) this longer
exposure penetrates the shadows.

When you edit a short exposure (cutoff=255) scan in software, all you
do is *show* the noise. You just make it more visible by brightening
it up in software.

That's why it's essential to use 16-bit depth for any post-processing.
Even thought 16-bit can't recreate the data which doesn't exists, it's
much more "forgiving" with the data that you do have.

>>>The interesting thing is that this "--gamma-correction" is applied *in
>>>addition* to the "--***-gamma-table" I supply.
>>
>> That is a bit strange.
>
>I found that weird too, but as I said previously, I'm starting to get
>used to this kind of things...
>
>But again, no matter how strange, it does show that the firmware is
>capable of applying trasformation to the lookup tables before applying them.

I think we can now slowly confirm your initial results.

There is definitely some weird processing going on especially with
regard to exposure. However, you've pretty much figured out *what* it
does and we can make some pretty good educated guesses *how* it's done
although we are both confused *why* it's done this way!?

But that doesn't matter. If you can get *repeatable* results - and you
can - then you can simply use this knowledge and not worry about *why*
Epson does it this way.

>> Gamma is usually done by end-user application. I've never heard of
>> firmware doing gamma, but it's possible.
>
>You can check, if you want to get the PDF from Epson with the ESC/I
>protocol reference. You'll see there is a command for setting gamma, one
>for setting "gamma tables" (i.e. the lookup tables we're working with),
>and one for setting color correction.

Oh, I believe you! It's just unusual.

>Look, I realize you've been nurtured by a real film scanner ;-)

Tortured, is more like it! ;o)

Kodachromes/Nikon! Grrrr... ;o)

>>>Really, there is some bug. How could cutoff = R1 G1 B1 gives different
>>>pixel values from cutoff = R1 G1 B51, *in the red and green channels*?
>>>They switch from 1 to 255 depending on what's in the *other* channels!
>>
>> That would simply be random noise and is to be expected. Actually,
>> that's exactly what I mean and why it's so hard (impossible!) to
>> measure anything in the shadow part. Especially using only 8-bit
>> accuracy!
>
>But *random* noise is supposed to be random! I get a scan where *all*
>the pixels are zero in (say) the red channel, and then in the following
>scan they are all 255 -- and the red channel LUT was *not* changed
>between the two scans, only the LUTs for the other two channels were!

I didn't realize the jump was that high. I thought you just meant a
few random pixels here and there are different.

With the above settings a jump from 0 to 255 is definitely wrong. I
would expect some difference between the two scans not only because of
noise but also because even two scans with the same setting are never
the same. Also, there is some leakage between channels where one
channel can "corrupt" a neighboring channel but such a drastic jump
from 0 to 255 is just too much.

>> No, we're talking about raw data. At gamma 1.0 there *is* continuity
>> at the left side. If you edit this in 16-bit it gives you a lot of
>> elbow room. An 8-bit scan also has continuity at gamma 1.0 but your
>> elbow room is virtually 0. Even the smallest edit will cause banding
>> and a comb histogram if you start with an 8-bit image.
>
>But that's what I meant.
>My point was that, even though you see a "nicer" histogram after editing
>the 16-bit image than the 8-bit one, much of that "niceness" is simply
>due to noise "filling up the gaps" in the histogram.

No, it's not! You do get more legitimate image data in a 16-bit image.

Another thing to keep in mind is that you can't see all this data with
a naked eye! Your monitor is 8-bit as are your eyes (!). Actually some
believe eyes are really only 6-bit. Therefore much of that data is
"invisible". However, it's essential for editing because you can do
much more before negative effects become visible.

>In other words, I think you'd see more posterization in the edited 8-bit
>image, but also think much of that posterization is there in the 16-bit
>version as well -- only masked by some noise that the 8-bit version
>can't reproduce.

The thing is that is *not* noise. It's data. Believe me, 16-bit is
essential to producing better results.

>> If, on the other hand, you start with a 16-bit image and edit it
>> followed by a conversion to 8-bit (for display or print) you will get
>> continuity in the histogram.
>>
>> As a test, convert a 16-bit image to 8-bit first and then apply
>> *exactly the same* edits and it would case all sorts of artefacts.
>
>But that's also because the image editor would be *working at 8-bit
>internally*, so each subsequent edit loses data.

Exactly!

>But try this instead: start with an 8-bit image, then *convert it to
>16-bit*, then make your edits, then convert it back to 8-bit.
>
>This is as opposed to your: start with a 16-bit bit image, then make
>your edits, then convert it to 8-bit.

And that will produce better results than staying in 8-bit! Indeed,
that's precisely what I do with images from my digital camera which
only generates 8-bit.

>I think you'd see that, with low-end scanners, the culprit is *the image
>editor* working at 8-bit internally, rather than the 16-bit image being
>(much) "better" from the start.

Believe me, even with low end scanners, 16-bit is always better if you
plan to edit images afterwards.

>>>Try this: possibly using a low-end scanner, scan an picture at 8-bit.
>>>Then play with the levels, boost gamma and whatever.
>>>The histogram will get "comby", like this one:
>>> http://ljl.150m.com/scans/hist1.gif
>>> from http://ljl.150m.com/scans/scan1.jpg
>>>
>>>Now apply some artificial noise to the image, such that it is just
>>>visible: you will get a continuous histogram again, like this:
>>> http://ljl.150m.com/scans/hist2.gif
>>> from http://ljl.150m.com/scans/scan2.jpg
>>
>> That's what I call "corruption" of data. This, BTW, is exactly what
>> Vuescan does to *mask* its original data because it's so bad.
>
>Please don't talk Vuescan to me... mom has told me that, when I join a
>newsgroup, it's good manners that I leave the flames to the regulars.

No, it's just a fact. Using noise in such a way is very good at hiding
original data regardless of what software uses it.

>Anyway, it's not really corruption of the data, as long as you take care
>that the noise *only* "fills in the gaps" in the histogram, without
>actually starting to overlap real data.

No, adding noise to an image is always corruption of data. If the data
is not there to start with you are "inventing" it.

I mean, this can produce visually pleasing results by eliminating one
problem, but it will create others. Adding noise is a known editing
method, but it's a method of last resort i.e. when there's no other
option.

If you do have a choice, you should always go with better initial
data, instead of trying to recreate it artificially later.

>But I think that, in principle, this would give you the same results as
>an equivalently "stretched" 16-bit scan -- if that scan was made with a
>scanner featuring a 16 bit A/D but without enough quality for data to
>really go beyond 8 bits per channel.

If there's no data to start with, that's another story. But I do
believe that even your low end scanner can get more than 8-bits.

Don.
.

Relevant Pages

  • Re: NOT scanning negatives as positives
    ... There is no mention of exposure *there*. ... >> Yes, but then it's not gamma anymore, but just a plain lookup table. ... Like the "detail" whether it's a film or a flatbed scanner! ... >> using Curves in Photoshop. ...
    (comp.periphs.scanners)
  • Re: NOT scanning negatives as positives
    ... (Flatbeds in general don't offer ... > exposure because they do that automatically and internally.) ... I wouldn't be surprised if my scanner didn't have exposure control. ... *send lookup tables to the scanner*. ...
    (comp.periphs.scanners)
  • Re: NOT scanning negatives as positives
    ... >> exposure because they do that automatically and internally.) ... >I wouldn't be surprised if my scanner didn't have exposure control. ... >>>Actually, there is some code in the driver to invert the image (well, ... I can tell with reasonable certainty that the curves *are* ...
    (comp.periphs.scanners)
  • Re: Scanner woes
    ... Gain i.e. exposure. ... after it has been retrieved from the scanner. ... VueScan users will be VueScan users... ... In the end I get the best images when I use VueScan so that is what I ...
    (comp.periphs.scanners)
  • Re: Scanning vs digital image
    ... But true grain itself is not noise: ... No matter how good your non-drum film scanner is, ... due to the very little diffusion of the light sources used. ...
    (comp.periphs.scanners)