Re: A "slanted edge" analysis program

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

[snip]

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.

But I'm not even ignoring it, since at the moment I haven't yet reached the point of trying to apply my "slanted edge" measurements to a *real* image.

What's the point of arguing that the "real" image should be 16-bit instad of 8-bit, when I currently have no way to test a "real" image?
When my program will be able to do that, then we'll see if a 16-bit image is needed.

Unless you mean...

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.

.... that I should *scan the slanted edge* at 16 bit -- as you say that it's the *measurement* that's inaccurate.

But, you see, Imatest's manual doesn't particularly insist on scanning the edge at 16-bit, and I think I can see the reason: the oversampling that the slant allows compensates very well for the low bit-depth.

You see, even if I scan the edge at 8-bit, the final edge spread function I obtain will have a *much higher* bit depth than 8-bit -- that's because I'm scanning the edge transition multiple times (200 times, if the scan is 200 pixels tall).

Wouldn't you think an image would get to have a much higher bit depth than 8 bit if you multi-scan it 200 times, even if each of the scans is made at 8-bit? :-)

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.

But, you see, the *metrics* are not inadequate (or at least, wouldn't be if my program wasn't full of bugs).
At worst, it's the (8-bit) scanned *picture* that's inadequate, but in that case, it can only be as inadequate for "guessing" as it is for using measured values!

That is, at most you should be able to obtain, by guessing, the *same* result I obtain with measurement, but no better.
Then, sure, using a 16-bit scan of the picture may well improve the results of *both* guessing and using measurements.

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...

Isn't that because of the haloes perhaps?
Halos are precisely one of the things I wish to avoid with the PSF method, which should be able to compute optimal sharpening that *doesn't* cause haloes.

I think the main problem will (still) be noise, as it will be amplified by the sharpening, and computing the PSF doesn't help much with that.

I think it's going to be a matter of compromise here: how much noise am I prepared to accept versus how much (or, up to what frequency) do I want to improve the MTF.

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.

Well, looking at the MTF graphs, I see that while my scanner does about 1500dpi on the CCD axis, it does something like 1300dpi on the motor axis.

Now, this is the resolution, not the color aberration, but I'm afraid it gives a measure of color aberration, too. Actually, I think color aberrations increase *more* than resolution decreases.

[snip: the ruler test]

I'll try, just for laughs (or cries).
But even after measuring what's going on with a ruler, I'm still afraid there is very little that can be done.

Possibly, one could scan a ruler next to the film, and use some program to "reshape" every color channel based on the positions of the ruler ticks... but, I dunno, I have a feeling this is only going to work in theory.

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.

More at the expense of blue, I think.
But, besides this, what you said before was that either average or luminance will not be right when the channels are misaligned.

What I'm saying is, well, this will be no issue, as the channels will be re-aligned *before* taking either average or luminance.
"Will", because this is not currently done in my program -- don't know about Imatest.

> [snip]
>
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.

But then why were 50% and (expecially) 10% chosen as standard?
Because of some physical reason? No, because they make perceptual sense: 10% is the boundary where the average human eye stops seeing contrast.

Sure, if you read the *whole* MTF instead of just MTF50 and MTF10, you don't have to chose an observer-dependent frequency; but, like it or not, MTF50 and MTF10 are standards. Sometimes it makes sense to follow standards.

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.

But you can express the number of colors a monitor can display with *one* number.

You can't express a scanner's "objective resolution" with one number; you must print an MTF grpah.
But what if you want a measure in ppi (which many people want)? Then you have to *choose a point* on the MTF, and the choice will be based on human perception: "you scanner can do 1500ppi [at 10% contrast, because that's what you will see at best]".
It follows that such a figure should be a *perceptually weighted* average of the three channels' values.

On the other hand, I can see some merit with using a simple average when presenting someone with the *whole* MTF graph.

But still, for the purpose of sharpening, Bart says color aberrations will occur if average is used instead of sharpening. We'll see how that works out (hopefully, if I can complete the program).

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.

Maybe, but it seems that Imatest is interested in the same, and Imatest doesn't look like it was written by idiots who didn't know what they were testing.

Anyway, let's end it here: my program will default to luminance, but will offer an option of using average, and it will always also show the three channels separately anyway.

The beauty of choice!


by LjL
ljlbox@xxxxxxxxxx
.