Re: A "slanted edge" analysis program

Don wrote: 
On Wed, 28 Sep 2005 15:28:36 +0200, "Lorenzo J. Lucchini"
<ljlbox@xxxxxxxxxx> wrote:


I've only been skimming this thread and not paying too much attention
because the MTF of my scanner is what it is and there's nothing I can
do about it... So, with that in mind...

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

So, you see, there is a practical application of the measurements I can obtain, it's not just about knowing how poor the scanner's resolution is. 

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'll start working with 16 bits, possibly after buying a USB 2 card, if that needs be.

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.

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!
I'm not an experienced photographer, quite the contrary, and I can't really tell how much unsharp masking "looks right".

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.

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

And why do you say I'm measuring the "objective values" of the pixels instead of their "perceptual values"? I'm mostly trying to measure resolution, in the form of the MTF. 

Because it's all based on those gray pixels which are created because
the scanner can't resolve that border area. So it's much better to
read the actual values of those gray pixels rather than take either an
average or luminance value.

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.

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

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.

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.

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.

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. The table I output has the fields "Frequency", "Red response", "Green response", "Blue response", "Luminance response".

If the users wants to take advantage of the luminance results, they can, but they also can ignore them just as well.


by LjL
ljlbox@xxxxxxxxxx
.

Relevant Pages

  • 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)
  • Re: Nikon Super CoolScan 4000 ED - some questions
    ... >It is worth noting that this interpretation of resolution, ... >is basically the number of pixels that the scanner samples per inch. ... >there is no film grain at the autofocus position, ... Of course the 4,000 ppi scans contain more information than the ...
    (rec.photo.digital)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... Without optical scaling it resolves 3600ppi, with optical scaling (as would be used in a scanner application) this can be set to match whatever the scanner width is - on the 8.5in flatbed scanner configuration that the OP is referencing, it would produce around 1200ppi. ... but it has no effect on the fact that this device will produce a resolution of 1200ppi on an 8.5" scan width. ... that the 10200pixel CCD is only capable of 3400ppi! ... The MTF of your example Kodak array is around 60% at Nyquist, ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... programming end of it, and it is something which simply does not interest me. ... >> CCD with RGB filtering over it. ... > Well, if you can suggest a simple method for measuring real resolution, ... > than the same picture taken directly at 2400x2400 dpi from the scanner. ...
    (comp.periphs.scanners)