That's what I ment when I said:
"I am thinking of a method but it makes a lot of assumptions
on the image content."
You actually assume that you can get the correction values
from the image data. If the color space is not very well
filled by your example image you may get strange effects.
If you know that there is no LUT applied you only need to
estimate the 4*4 matrix (or at least the 4 values for the IRED).
If there are LUTs applied you have to find out the LUTs too.
I haven't tried it, but I guess it is pretty tough
to estimate the LUTs only from the supposed correlation
values. If the colors are not equally distributed you may
get strange results.
I hope the calculation time for the color space correction
is sufficient low that we can do it faster than the
scanning so will not slow it down.
> > Maybe I'll add a raw format option that writes all data
> > without transformation to a 64Bit image (4*16) to
> > be used by a program that can do the Coolscan specific dust-removal
> > and which can apply the LUT afterwards.
>
> I'd be much obliged, this is exactly what I want.
>
> > This type of data-flow is basically optimized for speed - meaning
> > you don't have to wait on the scanner and the scanner doesnt
> > have to wait for the dust removal -
>
> My upcoming new frontend does all processing on the fly with priority
> to reading the scan data, meaning both scanner and CPU will work at
> full speed. This would be another reason to at least have the option
> to do defect removal in the frontend.
Can (or will) your programm read 16*3 Bit color images,
display them, allow the application of a LUT and save the resulting
image to a 8-Bit file?
You don't actually have to do the processing in the frontend
to get the CPU and scanner working at full speed, it is
also possible inside the backend.
I will try to use the scsi_request... stuff to parallelize
scanning and infrared-correction.
>
> > it is not because I hope
> > there will be a general way to treat these images.
>
> I gather you haven't had too much luck with it yet but damnit it must
> be possible!
I will continue implementing the color correction and the dust-removal
in the backend (and in a plugin).
When it is done and we find another scanner that makes
use of it, we can easily extract it and move it to a frontend.
>
> > While the 4*4 transformation can be done "on the fly" pixel per pixel
> > without having all the image available, the dustremoval needs
> > the whole image (or parts of it) to do spacial interpolation.
>
> You don't really need the whole image, a few scanlines are sufficient
> to do the interpolation (I have done this once). So it is possible to
> do on the fly too. You just use already interpolated pixels for
> interpolating the lower defects.
If we know our thresholds and parameters all in advance we can actually
do the interpolation on a smaller region.
But if we want to estimate all the correction values (as you suggested above)
then we need a max of image statistics and we better get the whole image.
My current dust-removal plugin only uses a small region to interpolate,
but I will need to do some refinement to treat overlapping regions so
that occluded pixels at the borders of that regions can be interpolated
correctly.
Greetings from Paris
Andreas
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com