Re: A "slanted edge" analysis program



On Fri, 30 Sep 2005 18:36:39 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:

>Unless you mean...

Yes, that's what I mean! ;o)

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

Bingo!

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

I don't know what Imatest manual says, but I suspect being a generic
type of test they compensate in advance just in case people do use
less that optimal bit depths.

But that doesn't mean one should use lower bit depths if one has more.

>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? :-)

Not really, especially not for flatbeds because of the stepper motor
inaccuracies. You will just blur the image more. Not to mention it
will take "forever" to acquire all those 100s of samples. And all
along you have a ready and (compared to 200 * 8-bit scans) a quick
solution i.e. 16-bit!

The point I'm making is why try to "fix" 8-bit when there is 16-bit
readily available? Now, if your scanner did *not* have 16-bit then,
yes, trying to get 8-bit as accurate as possible makes sense.

But having said that, in my life I've done even sillier things (much,
*much*, sillier things!) simply because they were fun. And if that's
the goal, than just ignore everything I say and have fun! :o)

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

Yes, 8-bit image is inadequate which results in inadequate metrics.

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

It will not improve guessing because we only have 8-bit eyes (some say
even only 6-bit) so you will not even be able to perceive or see the
extra color gradation available in 16-bit. But *mathematics* will!

>> 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 is just one thing, but I don't like the concept behind it, that
edges are changed in such a drastic way.

The problem is the image is *not* made sharper but the contrast of
transition between dark and light is simply increased because humans
perceive high contrast as sharpness. It's an optical illusion, really.

That's what bothered me, conceptually. The image was degraded in order
to generate an optical illusion and that just doesn't make sense to
me. It's like anti-aliasing (which I *HATE*!) and which *pretends* to
"remove" jaggies by blurring everything!!! To me, that's madness! But
that's just me... ;o)

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

By definition (because of increased contrast) it will cause haloes.
Whether you see them or not is another matter. If you zoom in and
compare to the original you will see them.

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

Yes, that's exactly what it boils down to! You have to balance one
against the other. Which means, back to "guessing" what looks better.

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

It will work in practice too if you have guides along both axis. The
trouble is that's very clumsy and time consuming.

If you do decided to do that I would create a movable frame so you
have guides on all 4 sides. That's because the whole assembly wiggles
as it travels so the distortion may not be the same at opposite edges.

Also, the misalignment is not uniform but changes because the stepper
motor sometimes goes faster and sometimes slower! So you will not be
able to just change the height/width of the image and have perfect
reproduction. You'll actually have to transform the image. Which means
superimposing a grid... Which means figuring out the size of that grid
i.e. determine the variance of stepper motor speed change... Argh!!

Of course, the key question is, is it worth it? In my case, in the
end, I decided it wasn't. But it still bugs me! ;o)

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

I would *not* align them because that would change the values!!! And
those changes are bound to be much more than what you're measuring!

In principle, you should never do anything to the data coming from the
scanner if the goal is to perform measurements. That's why even gamma
is not applied but only linear data is used for calculations.

I really think the best way is to simply do each channel separately
and then see what the results are. In theory, they should be pretty
equal. If you want a single number I would then just average those
three results.

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

No, there is physical reason why those luminance percentages were
chosen. It's to do with how our eyes are built and the sensors for
individual colors.

I mean, if you're measuring how fast a car is going, are you going to
change the scale because of how you perceive speed or are you going to
ignore your subjective perception and just measure the speed?

This is the same thing. You measure the amounts of gray the scanner
can't resolve. How you perceive this gray is, is totally irrelevant to
the measurement.

Now, if you want to measure *your perception*, that's a different
thing altogether. But before you measure something as subjective as
individual perception, you still need objective measurements as a
starting point and a baseline.

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

Bart has a tendency to be literal and just repeats what he reads
elsewhere without paying enough attention to context. Mind you, it's
good information with good links and I often save his messages because
of that, but it's really just repeating stuff seen somewhere else.

I mean, in this case Bart may very well be right, but I'd ask Kennedy
because Kennedy thinks laterally and actually analyzes what the
implications are in the full context.

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

They may be testing a different thing, though. BTW, why don't you just
use Imatest?

Anyway, as I said on the outset. I'm just kibitzing here and threw in
that luminance note because it seemed contradictory to the task.

But instead of wasting time on replying carry on with programming! :o)

Don.
.



Relevant Pages

  • Re: A "slanted edge" analysis program
    ... The "16-bit quick solution" don't change much for scanning a slanted edge, as you have to do the oversampling anyway. ... another bug in my fine scanner driver! ... results of *both* guessing and using measurements. ... *can* apply some amount of sharpening that doesn't cause "hills" in the ...
    (comp.periphs.scanners)
  • Re: "near field" speaker measurement
    ... measure latency for the channel connecting to the speaker terminals. ... There is an infinite number of things to do with the frequency measurements so I figured ... of the low pass filter is actually 1/2 the bandwidth of the sweep measurement. ...
    (rec.audio.tech)
  • Re: Kenmore Microwave Oven - 2 failures in 2 years
    ... guide. ... I have seen pictures of guides - a small channel to direct the ... AKA a duct to carry the RF into the oven ... measurements. ...
    (sci.electronics.repair)
  • Re: Kenmore Microwave Oven - 2 failures in 2 years
    ... guide. ... I have seen pictures of guides - a small channel to direct the ... AKA a duct to carry the RF into the oven ... measurements. ...
    (sci.electronics.repair)
  • Re: How bad is that Behringer Crap, anyhow?
    ... IME there is a lot of bad gear that measures good, ... varied either up or down from channel to channel. ... variability of cheap linear pots. ... My hope was that there would be something really bad in the measurements ...
    (rec.audio.pro)