Hi Jan, hello Klaus,
Am 12.09.2012 16:03, schrieb Vleeshouwers, J.M.:
> Hi Michael (& Klaus),
>
> Summarizing (from 2 messages):
> - Streaming image data to the frontend is not possible, since we want the
> backend to be able to do dust/scratch removal. Of course there must be an
> option to retrieve raw RGBI data. So: no streaming. Sane_start() will read
> all the image data from the scanner into a buffer and do the post-processing
> to arrive at a complete image. Sane_read() will just return requested parts
> of the data.
Actually there are three cases, a) delivering raw data as for a preview,
b) postprocessing of a whole image where you know the dimensions in
advance, c) auto crop processing. c) has to be done completely in
sane_start, reading for b) can be initiated from sane_read. For a)
sane_start just starts the reader thread and returns. You suggest the b)
case, and I think it is a good starting point. Addition of a) and c) are
not so difficult.
> - A separate reader process is not necessary, since the whole image is
> available as soon as sane_start() finishes .
See above. It would be nice to see the preview appear in xsane though.
> - We'll stick to the indexed format when reading data from the scanner. No
> problem, since we already have to buffer internally.
> - Memory usage is an issue. Our backend should be able to handle an image of
> about 0.5 GB (7200 dpi, 16 bit depth, 4 colors), with perhaps the same amount
> of data for processing. Some resource checks before starting the scan might
> be welcome, but I don't know how to do that yet.
Agreed.
> I'm curious about the dust/scratch-removal. I understand the idea of finding
> appropriate thresholds to distinguish between image and artifacts, but I get
> lost in the image correction process ('dilating'). Do you have any literature
> on this process?
Definition: http://homepages.inf.ed.ac.uk/rbf/HIPR2/dilate.htm
Implementation: http://ostermiller.org/dilate_and_erode.html
When you read down the second URL to the Manhattan distances, you will
see that I not only calculated a distance map but also built an index
map which for each dirty pixel contains the linear index of the closest
clean pixel. So replacing dirty pixels becomes trivial and fast.
>
> I'm also curious if you have contacted Emre Celebri already about using his
> algorithms.
Not yet, but I will.
>
> Finally: if you are willing to go through my code to find out where your
> scanner should be treated differently, I shall implement the above, and also
> try to add the post-processing functions. I was a little too enthusiastic in
> sending working code (September 6th), because it is not obvious how to get it
> to compile (sorry, Klaus). I'll be clearer next time, which I hope is before
> you return from your upcoming internetless time.
>
> Yours,
>
> Jan
I think that once we have a minimal backend which works for more than
one of us we could start helping each other. I could fit in calibration,
shading correction, dust removal, cropping as I did it already once.
Regards
Michael
