Re: A "slanted edge" analysis program

On Thu, 29 Sep 2005 18:16:04 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:

>>>Well, but I don't plan to stop here. What I'd mostly like to obtain from
>>>all this is a way to "sharpen" my scans using a function that is
>>>tailored to my scanner's specifics (rather than just "unsharp mask as I
>>>see fit").
....
>>
>> I agree with that in principle. However, in practical terms I think
>> that starting with an 8-bit image there's only so much accuracy you
>> can achieve.
>
>Don't be so fixated with my 8 bits.

I'm not. It's simply a very important factor when considering the
context because it directly affects the result. So to ignore it would
lead to wrong conclusions.

>> I strongly suspect (but don't know for a fact) that you will not be
>> able to show a demonstrable difference between any custom sharpening
>> and just applying unsharp mask at 8-bit depth.
>
>Well, wait a minute: at any rate, I'll be able to use a *measured* --
>instead of just *guessed* -- amount (and kind) of sharpening.

But that measurement will be so inaccurate as to be virtually
meaningless i.e. the margin of error will be so high that it will not
improve on the guessed amount. Indeed it's quite conceivable that in
significant number of cases it may actually produce worse results than
guessing.

>Then I guess you'll be able to obtain the same results by using a "right
>amount" of unsharp masking... but that's precisely what I want to avoid,
>guessing values!

Please don't get me wrong. I hate guessing. But if the metrics are
inadequate then you may end up making matters worse. I mean you, can't
measure millimeters with a ruler that only has marks for centimeters.

>I'm not an experienced photographer, quite the contrary, and I can't
>really tell how much unsharp masking "looks right".

On a tangent, I personally don't use any sharpening at all. I compared
sharpened images to the originals (at large magnification) and didn't
really like what unsharp mask did. But, that's a matter of personal
taste...

>> I think you can improve the sharpness considerably more (even at 8-bit
>> depth) by simply aligning individual channels to each other.
>
>That's another possibility to explore, sure. Imatest, SFRWin and my
>program all give some measurement of color aberrations -- channel
>misalignment, chiefly.

I was shocked when I discovered this on my film scanner. I expected
that the channel alignment would be much more accurate.

>Certainly, those values could find some use; however, I don't have much
>hope: in fact, unsurprisignly, my scanner seems to have very little
>color misalignment in the CCD direction, but it does show quite a bit of
>misalignment in the motor direction!

Yes, that's a very big problem with all flatbeds! The stepper motor is
also very irregular as the belts slip, etc.

>But, I thought, that must be because the motor's steps are not very
>regular and precise. If that's the cause, then it'll be impossible to
>try and re-align the colors, as misalignment will change at every scan line.
>
>Sort of like what you've found out with multi-pass scans alignment..

Here's a little test to try: Take a ruler and scan it twice at optical
resolution of your scanner: once horizontally, and once vertically.
Rotate one of them and compare! It makes a grown man cry! ;o)

Now, if that weren't bad enough, do several vertical scans (along the
stepper motor axis) and compare! And then really start to cry! ;o)

It sure made me pull my hair! I noticed this when I was scanning some
square images and was surprised that their vertical vs. horizontal
dimensions in Photoshop were not the same. I then rotated the photo,
scanned again, and now it was stretched in the other direction!
Aaaaarrrrggghhh!

That's when I invented "the ruler test". My scans on stepper motor
axis are about 1mm shorter than scans on CCD axis using a 10cm strip.

>> If the three RGB channels are not perfectly aligned (and they never
>> are!) then combining them in any way will introduce a level of
>> inaccuracy (fuzziness). In case of luminance that inaccuracy will also
>> have a green bias, while the average will be more even - which is why
>> I said that your original idea to use average seems like the "lesser
>> evil" when compared to the skewed and green-biased luminance values.
>
>At this point, I think I have a better idea: let's *first* measure the
>amount of misalignment, and then average the channels to luminance
>*after* re-aligning them.

That's what I'm saying (individual channel measurements) only use a
straight average when you combine the results. Luminance will simply
introduce a large green bias at the expense of red, for the most part.

Luminance really has no part in this context because it only skews the
results by favoring the green channel results and neglecting the red.

>Of course, I must first be sure the way I currently measure misalignment
>is correct, as SFRWin gives different results.
>But that's (by far) not the only thing that's currently wrong in my
>program...

That's why we like programming! ;o) It's solving those problems!

>>>So you see that I'm *already* doing measurements that are inherently
>>>"perceptual". So why not be coherent and keep this in mind throughout
>>>the process?
>>
>> Because perception is subjective. When there is no other way, then
>> yes, use perception. But since you already have the values of those
>> gray pixels it just seem much more accurate to use those values.
>
>I'm not sure. Yes, I have the real values, but... my program tries to
>answer the question "how much resolution can my scanner get from the
>original?". The answer itself depends on the observer's eye, as a person
>might be able to see constrasts less than 10%, and another might only
>see up to 15%, say.

No, the answer is not based on any one individual person. The answer
is quite clear if you read out the gray values. Whether one person can
see those grays and the other can't doesn't really matter in the
context of objective measurements.

>So, since an average observer *must* be "invented" anyway for the
>results to have any practical meaning, then it makes sense to also
>adjust them so that the colors the average eye sees best count more, as
>they *will* affect perceived resolution.

If you want to test human perception that's a completely different
test. However, that doesn't change the *objective* resolution of the
scanner.

I mean take number of colors on a monitor. You can objectively
determine how many colors your monitor can display. And then you can
also determine how many of those colors an average person can
distinguish. Those are two totally different test, using different
metrics.

>And "perceived resolution" is the only viable metric: in fact, if I
>wanted to measure "real" resolution, I would have to say that my scanner
>really does resolve 2400 dpi (which it doesn't), as just before Nyquist,
>there is (for example) a 0.00001 response.
>Hey, that's still resolution, isn't it! But it's resolution that counts
>nothing, as no observer will be able to see it, and sharpening won't
>help because noise will overwhelm everything else.

In that case, it appears you're not really interested in your
scanner's actual resolution but your perception of that resolution.
And that's a different test.

>>>>Actually, what I would do is measure each channel *separately*!
>>>
>>>... I'm doing this already.
>>>The "gray" channel is measured *in addition* to the other three
>>>channels, and is merely a convenience.
>>
>> That's good. So displaying individual results should be easy.
>
>Not should, is.

It's a figure of speech.

Don.
.

Relevant Pages

  • Re: What is better Nikon Super Coolscan 4000 or Coolscan V ED?
    ... >>whether you can actually achieve higher resolution even with misaligned ... You say you have *built* systems where it works. ... As I said in the part you snipped, normal consumer-grade scanner ... How is any software going to correct for misalignment that, ...
    (comp.periphs.scanners)
  • Re: What is better Nikon Super Coolscan 4000 or Coolscan V ED?
    ... > cannot afford a scanner with a really high resolution. ... The top may have some amount of average misalignment, ...
    (comp.periphs.scanners)
  • Re: How does the LS-2000 stack up today?
    ... >I have decided I should be looking for a film scanner with an IR ... >Can anyone recommend another option for a scanner with an IR channel ... There are two aspects to resolution. ...
    (comp.periphs.scanners)
  • Re: Sprintscan 35+, 10 bits vs 8 bits
    ... most scanning programs preview at what they consider "enough" resolution. ... You're still stuck in the scanner program with inadequate and limited set of editing tools. ... 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). ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... > The KLI-10203 is a tri-linear CCD (check the FIRST line of the data ... > application) this can be set to match whatever the scanner width is - on ... that resolution is based on actual tests of scanners ... What you are missing is that not all scanning systems in flat beds use a "pass" in ...
    (comp.periphs.scanners)