| Author |
Message |
Bart van der Wolf
Guest
|
 Posted:
Wed Sep 28, 2005 9:15 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:aVw_e.1452$133.727@tornado.fastwebnet.it...
SNIP
| Quote: | I'm not sure. Besides Bart, I think I've read somewhere else that
luminance should be used in this process. Perhaps it's even in the
ISO recommendations.
|
The ISO allows to test whatever one wants, single channels or weigthed
combinations of more than one, whatever suits the purpose, but a
formal test of a device should include R+G+B measurements. However, to
quote them "If desired, a luminance resolution measurement may be made
on a luminance signal formed from an appropriate combination of the
colour records".
Since the purpose is sharpening (which should be done in the Luminance
channel if you want to avoid colored artifacts), it only makes sense
to use a weighting that simulated the luminance sensitivity of the
human eye.
Imatest also calculates a Y channel for luminance (and that was not an
uninformed choice), as it is the most significant for the sensation we
call 'sharpness'. With human eyes, color resolution is much lower than
Luminance resolution.
| Quote: | 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. People usually cite the
MTF50 and the MTF10, because these are points where it *makes
perceptual sense* to measure: MTF10 is about the point where the
human eye cannot discern contrast anymore, Bart said.
|
You don't have to take my word, but this is what the ISO says:
"A very good correlation between limiting visual resolution and the
spatial frequency associated with a 0,10 SFR response has been found
experimentally. Should this frequency exceed the half-sampling
frequency, the limiting visual resolution shall be the spatial
frequency associated with the half-sampling frequency".
SNIP
| Quote: | In any case, it makes sense to conform to what other programs of
this kind do, so that the results can be easily compared.
|
There are many different opinions on what the mix should be.
If you want to exactly match Imatest, you could use
Y=0.3*R+0.59*G+0.11*B
(http://www.imatest.com/docs/sfr_instructions2.html almost
halfway down the page under Channel).
Other researchers use L=0.299R+0.587G+0.114B .
And Luminance weighting according to ITU-R BT.709 is:
Y=0.2125*R+0.7154*G+0.0721*B
which comes close(r) to:
<http://hyperphysics.phy-astr.gsu.edu/hbase/vision/efficacy.html#c1>
Whatever the choice (ultimately user selectable would be best for
flexibility, but makes comparisons more hazardous), I think Human
perception should carry some weight when the goal is to optimize
sharpening.
Bart |
|
| Back to top |
|
 |
Lorenzo J. Lucchini
Guest
|
| Posted:
Wed Sep 28, 2005 9:29 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
Bart van der Wolf wrote:
| Quote: |
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:aVw_e.1452$133.727@tornado.fastwebnet.it...
[snip]
There are many different opinions on what the mix should be.
If you want to exactly match Imatest, you could use
Y=0.3*R+0.59*G+0.11*B
(http://www.imatest.com/docs/sfr_instructions2.html almost
halfway down the page under Channel).
Other researchers use L=0.299R+0.587G+0.114B .
And Luminance weighting according to ITU-R BT.709 is:
Y=0.2125*R+0.7154*G+0.0721*B
which comes close(r) to:
http://hyperphysics.phy-astr.gsu.edu/hbase/vision/efficacy.html#c1
Whatever the choice (ultimately user selectable would be best for
flexibility, but makes comparisons more hazardous), I think Human
perception should carry some weight when the goal is to optimize
sharpening.
|
I think I'll go for user selectable, with a default that's recommended
for comparing others' results.
But all this made me wonder about something else: would it make any
sense to compare the edge *position* of each (red, green and blue)
channel with the edge position in the luminance channel?
I mean. SFRWin gives "red", "blue" and "green" color offsets (for
measuring "color fringing"), but the "green" offset is always zero, as
the other two channels are compared to green.
Would comparing the three channels to luminance, instead, have any
advantage over SFRWin's approach? I don't remember what Imatest does here.
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Bart van der Wolf
Guest
|
| Posted:
Wed Sep 28, 2005 10:06 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:L3l_e.674$133.670@tornado.fastwebnet.it...
| Quote: | Bart van der Wolf wrote:
SNIP
The image code values should be linarized at this stage,
so film/sensor non-linearity and gamma adjustments
can't influence the calculations.
Yes, I am currently ignoring gamma, as my test images
are gamma=1.0 anyway.
|
For real accurate results, that remains to be verified ...
Testing a (transparent) step wedge may/will reveal 'interesting'
features of hardware *and* of scanner driver software.
| Quote: | If I'm not mistaken, though, this all boils down to a
"Pixel=InputPixel^Gamma" instead of just "Pixel=InputPixel",
so I'll > be be very easy to add.
|
Yes, for straight Gamma only (sRGB profiled images use a
'slope-limited' Gamma). Also beware that Gamma adjustment
may mean 1/Gamma, depending on what is being adjusted where.
This does assume that Gamma is the only non-linearity.
SNIP
| Quote: | I think that, especially on non-linear image codes, this will
influence the MTF results, because the contrast is expanded.
On a perfectly symmetrical brightness distribution its effect
will be small, but the possibility of clipping in later stages
should be avoided.
I'm not sure I understand why it can affect the MTF, but I'll take
your word for it.
|
Assume all it takes is a lowering of the highlight clipping point,
which essentially is the same as multiplying all luminance levels by a
fixed factor. That would work out differently for shadows/highlights
if the response was non-linear.
SNIP
| Quote: | Also a check for at least 20% edge modulation should be made, in
order to avoid a too low input S/N ratio.
I'm taking note, but I think I'll leave such checks for later when
the program is somewhat stable.
|
Obviously, I know how actual programming works (tackle large issues
first, and get a working alpha version before working on the 'icing of
the cake'), but just don't forget some obvious boundary checks in the
end.
| Quote: | It is however perfectly normal to normalize the ESF output to a
range between 0.0 and 1.0, and later to normalize the SFR/MTF to
1.0 (100%) at zero spatial frequency.
Currently, I'm normalizing the ESF, the LSF and the MTF to between
0.0 and 1.0.
|
Just note that actual MTFs can exceed 1.0, assuming correct
normalization to 1.0 at zero cycles. Edge sharpening halo can achieve
that easily.
SNIP
| Quote: | The ISO suggests to [...] determine the centroid of the LSF (by
calculating the discrete derivative of the ESF). The centroids can
be used for regression.
The derivative suggested by the ISO is:
"for each line of pixels perpendicular to the edge, the edge is
differentiated using the discrete derivative "-0,5 ; +0,5", meaning
that the derivative value for pixel "X" is equal to -1/2 times the
value of the pixel immediately to the left, plus 1/2 times the
value of the pixel to the right".
Sorry if I'm thick, but mathematics isn't my best friend...
|
Hey, I also know my limitations in that field ... ;-)
| Quote: | You're implying that, for each line of pixels, the edge center(oid?)
will be the absolute maximum of the above derivative, aren't you?
|
Yep.
| Quote: | But isn't the absolute maximum of the derivative precisely the
maximum gradient?
|
Rereading it, yes, but it actually is where the increasing contrast
turns into decreasing contrast (the first derivative being the slope
of the curve).
| Quote: | (Though the formula I use is currently simpler than the one you
cite: simply y'[i]=y[i+1]-y[i])
|
Yes, and it'll produce a difference, but actual nodes will on average
be displaced by half a pixel. Nevertheless, the sample code from
the ISO seems to do what you did, so I'd suggest leaving it that way.
SNIP
| Quote: | See earlier remark, and provisions need to be made to detect
multiple maxima (caused by noise/graininess).
What kind of provisions?
|
With noisy images, there can be multiple LSF maxima from a single ESF.
One should decide which maximum to take. I dug up some old Word
document with C code for the SFR calculation. It takes the average
between the leftmost and rightmost maxima.
If your email address in your signature is valid, I can send you that
document.
SNIP
| Quote: | Even though the SourceForge description currently says little more
than "calculates the MTF from a slanted edge", ultimately I'd like
this program to do automatic deconvolution (or whatever is best) of
images based on the edge results.
|
Yes, that's a good goal, although it will take more than a single
slanted edge to get a two-dimensional a-symmetric PSF). What's worse,
the PSF can (and does) change throughout the image, but a symmetrical
PSF will already allow to improve image quality.
Some hurdles will need to be taken, but the goal is exactly what I am
looking for.
SNIP
Yes, we're not the only ones still looking for the holy grail, it
seems.
I'm working on a method that will produce a PSF, based on the ESF
derived from a slanted edge. That PSF can be used in various
deconvolution methods, and it can be used to create a High-pass filter
kernel. Could be useful to incorporate in the final program.
Bart |
|
| Back to top |
|
|
Bart van der Wolf
Guest
|
| Posted:
Wed Sep 28, 2005 10:58 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:nim_e.699$133.298@tornado.fastwebnet.it...
SNIP
Thanks. Unfortunately I get an error box with:
"This application has failed to start because cygwin1.dll was not
found".
SNIP
| Quote: | At
http://ljl.741.com/comparison.gif
there is a a graph showing the MTF calculated both by my program and
SFRWin, from the test image included in the archive.
|
The test image looks a bit odd. It seems like the edge was resized
vertically with a nearest neighbor interpolation. The edge pixels look
like they are 2 pixels high and 1 pixel wide. The noise in the image
is single pixel noise (and has a bit of hardware calibration
striping).
It looks strange, and thus produces strange sharpening artifacts if
pushed to the limits (deconvolution sharpening with a derived PSF, and
a Richardson-Lucy restoration with the same PSF). Nevertheless, the
Imatest SFR analysis looks identical to the SFRWin result.
Bart |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Wed Sep 28, 2005 11:19 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
Bart van der Wolf wrote:
Yeah, it's the Unix emulation layer that Cygwin compiled programs
apparently need.
I've uploaded it at
http://ljl.741.com/cygwin1.dll.gz
http://ljl.150m.com/cygwin1.dll.gz
Putting it in the same directory as the program should work, as should
putting in in \Windows\System32.
| Quote: | SNIP
At
http://ljl.741.com/comparison.gif
there is a a graph showing the MTF calculated both by my program and
SFRWin, from the test image included in the archive.
The test image looks a bit odd. It seems like the edge was resized
vertically with a nearest neighbor interpolation. The edge pixels look
like they are 2 pixels high and 1 pixel wide.
|
It could be: I've scanned some edges at 2400x4800 and resized them down
to see how this affected the MTF (remember the thread "Multi-sampling
and 2400x4800 scanners").
Obviously, I'm stupid enough to give very meaningful names to my files
such as "edge1.tif", "edge2.tif", "edgehg.tif", so it's entirely
possible that I took the wrong edge =)
I guess the next tarball will contain a freshly scanned edge, to avoid
this confusion.
| Quote: | The noise in the image is
single pixel noise (and has a bit of hardware calibration striping).
|
What is single pixel noise -- or, is it "single pixel" as opposed to what)?
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Thu Sep 29, 2005 12:24 am Post subject:
Re: A "slanted edge" analysis program |
|
|
Bart van der Wolf wrote:
| Quote: |
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:L3l_e.674$133.670@tornado.fastwebnet.it...
Bart van der Wolf wrote:
SNIP
The image code values should be linarized at this stage,
so film/sensor non-linearity and gamma adjustments
can't influence the calculations.
Yes, I am currently ignoring gamma, as my test images
are gamma=1.0 anyway.
For real accurate results, that remains to be verified ...
Testing a (transparent) step wedge may/will reveal 'interesting'
features of hardware *and* of scanner driver software.
|
True. But test targets cost money, and I'm allergic to expenses ;-)
Well, sooner or later, perhaps I'll go buy an IT8 test target, so that I
have a gray scale for measuring gamma, as well as everything else for
measuring colors.
But not right now. Actually, one of the reasons why I got very
interested in this slanted edge test was its astonishing inexpensiveness :-)
By the way, can the test somehow also tell something about color
corrections? Intuitively, it seems to me that with the ESF and the MTF
for red, green and blue one should be able to fix at least *some* color
correction parameters.
| Quote: | If I'm not mistaken, though, this all boils down to a
"Pixel=InputPixel^Gamma" instead of just "Pixel=InputPixel",
so I'll > be be very easy to add.
Yes, for straight Gamma only (sRGB profiled images use a
'slope-limited' Gamma). Also beware that Gamma adjustment
may mean 1/Gamma, depending on what is being adjusted where.
This does assume that Gamma is the only non-linearity.
|
But if I'm not mistaken, Imatest does the same, so I can be content with
it right now.
SFRWin on the other hand allows one to specify a look-up table.
| Quote: | [snip]
Just note that actual MTFs can exceed 1.0, assuming correct
normalization to 1.0 at zero cycles. Edge sharpening halo can achieve
that easily.
|
Right. I'll have to fix this, as the program currently doesn't give the
zero-cycles point any special treatment, but just normalizes.
| Quote: | [snip]
See earlier remark, and provisions need to be made to detect
multiple maxima (caused by noise/graininess).
What kind of provisions?
With noisy images, there can be multiple LSF maxima from a single ESF.
One should decide which maximum to take. I dug up some old Word document
with C code for the SFR calculation. It takes the average between the
leftmost and rightmost maxima.
If your email address in your signature is valid, I can send you that
document.
|
Yes, it's valid. It's usually full because of spam, but I'm keeping it
clean lately... just don't put "enlargement" in the subject and I should
receive it :-)
Anyway, can noise really cause such problems, besides in "extreme"
situations (i.e. when the measurments would be better thrown away anyway)?
I'm thinking that even a very high spike of noise shouldn't be able to
get higher than the edge constrast, considering that *many* lines are
averaged together to obtain the ESF...
Perhaps *very* bad calibration striping could cause that, but then again
one should probably throw away the scan in such a case.
| Quote: | SNIP
Even though the SourceForge description currently says little more
than "calculates the MTF from a slanted edge", ultimately I'd like
this program to do automatic deconvolution (or whatever is best) of
images based on the edge results.
Yes, that's a good goal, although it will take more than a single
slanted edge to get a two-dimensional a-symmetric PSF).
|
Well, I assume that a vertical+horizontal edge measurement can be
accurate enough for many purposes.
By the way, I've done (but not published) some tests on horizontal edges
(i.e. stepping motor resolution), and the results are a bit depressing!
About 100-200 dpi lower resolution than on the CCD axis, and a
frightening amount of color fringing.
| Quote: | What's worse,
the PSF can (and does) change throughout the image, but a symmetrical
PSF will already allow to improve image quality.
Some hurdles will need to be taken, but the goal is exactly what I am
looking for.
|
Well, it's a bit soon for this perhaps, but... how do I obtain the PSF
from two (h+v) ESFs?
Perhaps for each point, average the two points on the ESFs that are at
the same distance from the "center" of the function, and weight the
average based on the angle between the points and the two (h+v) axes?
But anyway...
| Quote: | SNIP
My main resource has been
http://www.isprs.org/istanbul2004/comm1/papers/2.pdf
where I took the evil alternative to the "4x bins" that I'm
currently using, with all the regression nighmares it brings ;-)
But it was an interesting document, anyway.
Yes, we're not the only ones still looking for the holy grail, it seems.
I'm working on a method that will produce a PSF, based on the ESF
derived from a slanted edge. That PSF can be used in various
deconvolution methods, and it can be used to create a High-pass filter
kernel. Could be useful to incorporate in the final program.
|
.... of course it can be useful. No need for me to invent the square
wheel when you've already worked on an octagonal one :-)
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Bart van der Wolf
Guest
|
| Posted:
Thu Sep 29, 2005 4:31 am Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:Gay_e.1611$133.572@tornado.fastwebnet.it...
SNIP
| Quote: | What do you propose for image restoration, instead of deconvolution?
("image restoration" obviously being restricted to the things you
can do when you have an ESF or PSF)
|
Straight deconvolution will 'restore' noise (and graininess) as well
as the signal itself, or the noise is even amplified. There are better
methods like the adaptive (damped) Richardson-Lucy algorithm, but that
is a very processing intensive and thus time consuming operation. The
method used in "Image Analyzer", using the "CGLS" algorithm, is much
faster but slightly noisier than RL.
<http://www.mathcs.emory.edu/~nagy/RestoreTools/index.html>
SNIP
| Quote: | So in your opinion it's ok if I just consider an arbitrary number of
pixels (like Imatest does) as constituting "the edge", without going
to great length trying to have the program make an educated guess?
|
Yes, although flatbed scanners exhibit a significantly wider ESF with
long tails. Don't be too conservative. The range used by Imatest is
from -6 to +10 in quarter pixel increments, and thus allows to handle
at least a symmetrical PSF with a support of 13 pixels, which would be
for a *very* blurry image.
SNIP
| Quote: | You'll have to window because of the abrupt edges. That's reality
in Fourier transforms, we deal with a small subset of the real data
which reaches out to infinity.
Yes, but there are two other options I've considered:
1) taking *many* DFTs of small (Hanning-windowed) pieces of the LSF,
and then average them together. Wouldn't this avoid the change of
LSF shape that using a single, big window may cause?
|
Although possible, it's probably more efficient to code the
binning/averaging many single row LSFs, thus approaching the real LSF.
It's the real LSF that needs to be 'DFT'ed. IMO it's not so useful to
perform many DFTs on such a small (e.g. 64 quarter pixels if ranging
from ) array, it becomes less efficient and I think complex. Some
calculations are easier/faster in the frequency domain (e.g.
deconvolution) and others in the spatial domain (averaging and small
kernel convolution). The windowing has only to be done once on the
multiple LSF average (which already has lower noise than single
samples).
| Quote: | 2) not using any window, but "cropping" the LSF so that the edges
are (very near) zero. Would this have any chances of working? It
would completely avoid changing the LSF's shape.
|
Truncation loses information, I don't think that's helpful. Windowing
will further reduce the already low response and it suppresses noise
at the boundaries. That's helpful.
SNIP
| Quote: | Yes, I do this.
MTF[i]=SquareRoot(ImaginaryPart[i]^2+RealPart[i]^2)
|
Depending on the library implementation, for complex numbers , Abs[z]
gives the modulus |z| .
Also note http://www.library.cornell.edu/nr/bookcpdf/c5-4.pdf (5.4.3)
which is a more robust way of doing it in extreme cases (which may
never occur, but it's still more robust).
| Quote: | - How many samples should my ESF/LSF have? I understand that it
only depends on how high you want your frequencies to be -- i.e.,
if I want to show the MTF up to 4xNyquist, I should have 4x more
samples than there are real pixels. Is this correct?
No.
Anyway, the method I'm using comes from the document I pointed to in
the other article, so it shouldn't be *too* stupid.
Still, the method you describe sounds much simpler to implement, so
I guess I'll go for it.
|
In the Netherlands we have a saying, "there are several roads, all
leading to Rome" ;-)
All I did is describe how the ISO suggests to do it, and it seems
relatively simple to code it. Simple code reduces the chance on bugs
and unforeseen 'features'.
| Quote: |
In the ISO method you would calculate an ESF for each line (row) of
pixels that crosses the edge. The average of all those ESFs is
produced after shifting each row in proportion with the centroid
regression. It is at that point, the shifting, that you bin the
pixels in an array that's 4x wider than the edge crop. That allows
you to bin the centroid with a 4x higher (=quarter pixel)
resolution. After that it's just statistics, larger numbers of ESFs
make a more likely approximation of the actual ESF.
Let us see if I've understood this.
[...] |
I think I have an even better suggestion. I have some C code examples
from the ISO that shows how it could be implemented. If I can email
the 48KB Word document (is your ljlbox@tiscali.it in the signature
valid?), it'll become quite clear, I'm sure. I also have a 130KB PDF
file you'll love to read because it describes the various steps and
considerations in more detail.
One more remark. I've been having some discussions with Fernando
Carello (also from Italy) about PSFs and types of restoration. He was
willing (if time permits) to attempt to tackle that side of the
challenge. Although I understand that it's always a bit difficult to
fathom a mix of programming styles, it could potentially help (again,
if his time allows).
Bart |
|
| Back to top |
|
|
Bart van der Wolf
Guest
|
| Posted:
Thu Sep 29, 2005 4:55 am Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:vyz_e.1841$133.1819@tornado.fastwebnet.it...
SNIP
| Quote: | I think I'll go for user selectable, with a default that's
recommended for comparing others' results.
|
Yep, seems like the pragmatic approach wins.
| Quote: | But all this made me wonder about something else: would it make any
sense to compare the edge *position* of each (red, green and blue)
channel with the edge position in the luminance channel?
|
Depends on what one wants to investigate, but I see no direct use for
comparison of a color channel with Luminance. Besides Luminance for
sharpness, one could compare R, G, and B for Chromatic aberrations. In
digicams with a Bayer CFA it can be quite revealing what a difference
Raw converters can make. For scanners that seems less of an issue.
| Quote: | I mean. SFRWin gives "red", "blue" and "green" color offsets (for
measuring "color fringing"), but the "green" offset is always zero,
as the other two channels are compared to green.
Would comparing the three channels to luminance, instead, have any
advantage over SFRWin's approach? I don't remember what Imatest does
here.
|
No advantage for me. Imatest produces a figure for Chromatic
Aberration (http://www.imatest.com/docs/tour_sfr.html#ca).
Bart |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Thu Sep 29, 2005 5:04 am Post subject:
Re: A "slanted edge" analysis program |
|
|
Bart van der Wolf wrote:
| Quote: |
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:Gay_e.1611$133.572@tornado.fastwebnet.it...
SNIP
[snip]
So in your opinion it's ok if I just consider an arbitrary number of
pixels (like Imatest does) as constituting "the edge", without going
to great length trying to have the program make an educated guess?
Yes, although flatbed scanners exhibit a significantly wider ESF with
long tails. Don't be too conservative. The range used by Imatest is from
-6 to +10 in quarter pixel increments, and thus allows to handle at
least a symmetrical PSF with a support of 13 pixels, which would be for
a *very* blurry image.
|
Well, I will use -10 .. +10 for now, if it doesn't get too slow (but
using the "4x bins" thing it should all go much faster, I think).
That should allow plenty of room.
| Quote: | SNIP
You'll have to window because of the abrupt edges. That's reality in
Fourier transforms, we deal with a small subset of the real data
which reaches out to infinity.
Yes, but there are two other options I've considered:
1) taking *many* DFTs of small (Hanning-windowed) pieces of the LSF,
and then average them together. Wouldn't this avoid the change of LSF
shape that using a single, big window may cause?
Although possible, it's probably more efficient to code the
binning/averaging many single row LSFs, thus approaching the real LSF.
It's the real LSF that needs to be 'DFT'ed. IMO it's not so useful to
perform many DFTs on such a small (e.g. 64 quarter pixels if ranging
from ) array, it becomes less efficient and I think complex. Some
calculations are easier/faster in the frequency domain (e.g.
deconvolution) and others in the spatial domain (averaging and small
kernel convolution). The windowing has only to be done once on the
multiple LSF average (which already has lower noise than single samples).
|
No, sorry, I didn't mean to take the DFTs of all single-row LSFs.
What I meant is:
- assume you have a (final) LSF that is 128 values long
- you take the windowed DFT of the first 16 values
- then you take the DFT of values from 8 to 24
- then from 16 to 32
- etc
- then you average all these together
I've not just invented this strange thing, I've read it somewhere,
though not in a graphics context, and I might have misinterpreted it.
| Quote: | 2) not using any window, but "cropping" the LSF so that the edges are
(very near) zero. Would this have any chances of working? It would
completely avoid changing the LSF's shape.
Truncation loses information, I don't think that's helpful. Windowing
will further reduce the already low response and it suppresses noise at
the boundaries. That's helpful.
|
I see. Well, at least I guess that taking a "longer" LSF (i.e.
considering more pixels "part of the edge") could help reduce any
artifacts caused by the windowing, since most of the "important" data is
in a small part of the whole LSF.
Also, do you think a Hanning window is a reasonable choice for my
purposes, or should I choose a different window type?
| Quote: | SNIP
Yes, I do this.
MTF[i]=SquareRoot(ImaginaryPart[i]^2+RealPart[i]^2)
Depending on the library implementation, for complex numbers , Abs[z]
gives the modulus |z| .
|
No, there isn't such a function in FFTW. However, there are functions to
directly obtain a real-to-real FFT; I probably should look at them,
although I'm not sure if the real data they output are the moduli or
simply the real parts of the transform's output.
Site down at the moment :-) I'm starting to worry that it may somehow be
me...
| Quote: | [snip]
In the Netherlands we have a saying, "there are several roads, all
leading to Rome" ;-)
|
Tutte le strade portano a Roma (all roads bring to Rome), clearly we
have that too, and in our case, it's actually true ;-) at least for
those roads that were originally built in ancient Roman times.
| Quote: | [snip]
Let us see if I've understood this.
[...]
I think I have an even better suggestion. I have some C code examples
from the ISO that shows how it could be implemented. If I can email the
48KB Word document (is your ljlbox@tiscali.it in the signature valid?),
it'll become quite clear, I'm sure.
|
It's valid, yes.
Only, how copyrighted is that stuff, and what's the legal state of those
documents? ISO might get upset with both of us, if somehow I wasn't
supposed to read or use their papers (ok, ok, in the real world they
won't even notice we exist I suppose).
| Quote: | I also have a 130KB PDF file you'll
love to read because it describes the various steps and considerations
in more detail.
|
Sure, if the main concepts can be understood without going too deeply
technical, it'll be most welcome.
| Quote: | One more remark. I've been having some discussions with Fernando Carello
(also from Italy) about PSFs and types of restoration. He was willing
(if time permits) to attempt to tackle that side of the challenge.
|
I've read through some of the threads you've had with him.
| Quote: | Although I understand that it's always a bit difficult to fathom a mix
of programming styles, it could potentially help (again, if his time
allows).
|
Sure! And if we work on separate aspects of the issue, the problem of
mixed programming styles is easily solved by having separate
sources/libraries communicate through an interface, you know, like I've
heard real programmers (rarely) do ;-)
Hm, I see a problem though... these PSF MTF ESF DFT regression curve
fitting etc thingies, I don't know how to call most of them in Italian :-D
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Bart van der Wolf
Guest
|
| Posted:
Thu Sep 29, 2005 5:14 am Post subject:
Re: A "slanted edge" analysis program |
|
|
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:1aB_e.2000$133.1794@tornado.fastwebnet.it...
SNIP
Getting closer, although now it complains about not being to locate
cygfftw3-3.dll (presumably the FFT routine library).
SNIP
| Quote: | The test image looks a bit odd. It seems like the edge was resized
vertically with a nearest neighbor interpolation. The edge pixels
look like they are 2 pixels high and 1 pixel wide.
It could be: I've scanned some edges at 2400x4800 and resized them
down to see how this affected the MTF (remember the thread
"Multi-sampling and 2400x4800 scanners").
|
Yes, that's what I was thinking of, interpolation in one direction to
compensate for the aspect ratio.
SNIP
| Quote: | The noise in the image is single pixel noise (and has a bit of
hardware calibration striping).
What is single pixel noise -- or, is it "single pixel" as opposed to
what)?
|
No, the edge seems to be NN interpolated, but the noise is not (there
are single (as opposed to 1x2 pixel) variations).
I'll wait for the next tarball, before making further benchmark tests.
Bart |
|
| Back to top |
|
|
Lorenzo J. Lucchini
Guest
|
| Posted:
Thu Sep 29, 2005 5:44 am Post subject:
Re: A "slanted edge" analysis program |
|
|
Bart van der Wolf wrote:
| Quote: |
"Lorenzo J. Lucchini" <ljlbox@tiscali.it> wrote in message
news:1aB_e.2000$133.1794@tornado.fastwebnet.it...
SNIP
Yeah, it's the Unix emulation layer that Cygwin compiled programs
apparently need.
I've uploaded it at
http://ljl.741.com/cygwin1.dll.gz
http://ljl.150m.com/cygwin1.dll.gz
Getting closer, although now it complains about not being to locate
cygfftw3-3.dll (presumably the FFT routine library).
|
Argh! I hoped that at least FFTW was linked statically.
Well,
http://ljl.741.com/cygfftw3-3.dll.gz
as well as, just in case
http://ljl.741.com/cygfftw3_threads-3.dll.gz
| Quote: | [snip]
Yes, that's what I was thinking of, interpolation in one direction to
compensate for the aspect ratio.
SNIP
The noise in the image is single pixel noise (and has a bit of
hardware calibration striping).
What is single pixel noise -- or, is it "single pixel" as opposed to
what)?
No, the edge seems to be NN interpolated, but the noise is not (there
are single (as opposed to 1x2 pixel) variations).
|
Oh, but I hadn't interpolated *up*, but resized *down*! I've resized the
4800dpi direction to 2400dpi. Anyway, this doesn't matter.
| Quote: | I'll wait for the next tarball, before making further benchmark tests.
|
It's there. As you might suspect, at
http://ljl.741.com/slantededge-alpha3.tar.gz
I haven't included the libraries, as they're a bit big and my server
doesn't let me upload more than 1 meg or so.
This time I'm positive there is no gamma and no color correction. I've
also used a brand new edge, which if I'm not mistaken is really a razor
blade this time! (No, I don't really know what a razor blade looks like.
So sue me :-)
Anyway, it seems quite sharp, probably sharper than the cutter I was
using before.
There is still something I don't quite understand: the program now
reports that the 10%-90% rise is about 6 pixels, while it was about 4-5
before (and Imatest agreed).
I don't think this is because of the edge, but rather because of the
fact I'm not normalizing the image anymore -- so 10% and 90% "take
longer" to be reached.
Should these 10% and 90% positions fixed as if the image were normalized?
by LjL
ljlbox@tiscali.it |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Sep 29, 2005 7:25 am Post subject:
Re: A "slanted edge" analysis program |
|
|
Lorenzo J. Lucchini wrote:
| Quote: | Depending on the library implementation, for complex numbers , Abs[z]
gives the modulus |z| .
No, there isn't such a function in FFTW.
|
FFTW is not a complex-number library. You can easily take the absolute
value of its complex number yourself by sqrt(re*re + im*im), or you can
use the standard C complex math library (or the C++ library via a
typecast).
| Quote: | However, there are functions to
directly obtain a real-to-real FFT; I probably should look at them,
although I'm not sure if the real data they output are the moduli or
simply the real parts of the transform's output.
|
Neither. The real-to-real interface is primarily for transforms of
real-even or real-odd data (i.e. DCTs and DSTs), which can be expressed
via purely real outputs. They are also for transforms of real data
where the outputs are packed into a real array of the same length, but
the outputs in this case are still complex numbers (just stored in a
different format).
Cordially,
Steven G. Johnson |
|
| Back to top |
|
|
Ole-Hjalmar Kristensen
Guest
|
| Posted:
Thu Sep 29, 2005 1:47 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
Here is an implementation of Glassman's method of FFT, which wil work
for any N, not just powers of two. If N is not a power of two, it
degenerates to a DFT. The code is lifted from PAL (Public Ada
Library), if I remember correctly, and I do not think there is any
restrictions on it. You will have to convert it to C of course, but
the code is pretty obvious even if yo don't know Ada. Just beware that
unlike C, Ada allows nested subroutines, and that arrays do not
necessarily start with index 0.....
with Ada.Numerics.Short_Complex_Types;
use Ada.Numerics.Short_Complex_Types;
package FFT_Pack is
type Complex_Vector is array(Integer range <>) of Complex;
procedure Debug(X : Complex_Vector);
procedure FFT (FFT_Data : in out Complex_Vector ;
Inverse_Transform : in boolean );
end FFT_Pack;
with Ada.Numerics.Short_Elementary_Functions;
use Ada.Numerics.Short_Elementary_Functions;
with Ada.Text_Io; use Ada.Text_Io;
package body FFT_Pack is
procedure Debug(X : Complex_Vector) is
begin
for I in x'Range loop
Put_Line(Integer'Image(I) & " : "
& Short_Float'Image(X(I).Re) & " "
& Short_Float'Image(X(I).Im));
end loop;
end Debug;
procedure Glassman (A, B, C : in integer;
Data_Vector : in out Complex_Vector ;
Inverse_Transform : in boolean ) is
Temp : Complex_Vector(1..Data_Vector'length);
Counter : integer := Data_Vector'first;
JC : integer := 0;
Two_Pi : constant short_float := 6.28318530717958;
Del, Omega, Sum : Complex;
Angle : short_float;
C_Plus_1 : integer := C + 1;
begin
Temp(Temp'Range) := Data_Vector;
Angle := Two_Pi / (short_float(A * C));
Del := (Cos(Angle), (-(Sin(Angle))));
if (Inverse_Transform) then
Del := Conjugate(Del);
end if;
Omega := (1.0,0.0);
for IC in 1..C loop
for IA in 1..A loop
for IB in 1..B loop
Sum := Temp((((IA - 1)*C + (C-1))*B) + IB);
for JCR in 2..C loop
JC := C_Plus_1 - JCR; -- No need to add C + 1 each
-- time through loop
Sum := Temp((((IA - 1) * C + (JC - 1)) * B)
+ IB) + (Omega * Sum);
end loop; -- JCR
Data_Vector(Counter) := Sum;
Counter := Counter + 1;
end loop; -- IB
Omega := Del * Omega;
end loop; -- IA
end loop; -- IC
end Glassman;
procedure FFT ( FFT_Data : in out Complex_Vector;
Inverse_Transform : in boolean ) is
A : integer := 1;
B : integer := FFT_Data'length;
C : integer := 1;
begin -- FFT
while (B > 1) loop -- define the integers A, B, and C
A := C * A; -- such that A * B * C = FFT_Data'length
C := 2;
while (B mod C) /= 0 loop
C := C + 1;
end loop;
B := B/C; -- B = 1 causes exit from while loop
Glassman (A,B,C, FFT_Data, Inverse_Transform);
end loop;
if Inverse_Transform then -- optional 1/N scaling for inverse
-- transform only
for i in FFT_Data'range loop
FFT_Data(i) := FFT_Data(i) /
short_float(FFT_Data'length);
end loop;
end if;
end FFT;
end FFT_Pack;
--
C++: The power, elegance and simplicity of a hand grenade. |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Thu Sep 29, 2005 8:53 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
On Wed, 28 Sep 2005 18:29:13 +0200, "Lorenzo J. Lucchini"
<ljlbox@tiscali.it> wrote:
| Quote: | But all this made me wonder about something else: would it make any
sense to compare the edge *position* of each (red, green and blue)
channel with the edge position in the luminance channel?
|
That would be a good test.
My point is that there's misalignment between individual channels, so
to combine them (using *any* method) reduces accuracy because the
result is a (fuzzy) mix of all of them. By doing channels individually
you should get more accurate measurements.
In other words (and all other things being equal) I would expect that
individual channels would differ much less in relation to each other,
then any one of them will differ in relation to the combined luminance
or average values.
| Quote: | I mean. SFRWin gives "red", "blue" and "green" color offsets (for
measuring "color fringing"), but the "green" offset is always zero, as
the other two channels are compared to green.
|
I would do a full permutation and compare all to each other.
Anyway, have fun! :o) And let us know how it turns out!
Don. |
|
| Back to top |
|
|
Don
Guest
|
| Posted:
Thu Sep 29, 2005 8:53 pm Post subject:
Re: A "slanted edge" analysis program |
|
|
On Wed, 28 Sep 2005 15:28:36 +0200, "Lorenzo J. Lucchini"
<ljlbox@tiscali.it> wrote:
| Quote: | 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.
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.
I think you can improve the sharpness considerably more (even at 8-bit
depth) by simply aligning individual channels to each other.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
Don. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in