kopia lustrzana https://gitlab.com/sane-project/website
136 wiersze
6.8 KiB
HTML
136 wiersze
6.8 KiB
HTML
<!-- received="Thu Aug 5 00:12:45 1999 PDT" -->
|
|
<!-- sent="Thu, 05 Aug 1999 09:11:10 +0200" -->
|
|
<!-- name="Andreas Rick" -->
|
|
<!-- email="rickand@gemse.fr" -->
|
|
<!-- subject="Dust-removal and color-correction" -->
|
|
<!-- id="37A9390E.11F797ED@gemse.fr" -->
|
|
<!-- inreplyto="" -->
|
|
<title>sane-devel: Dust-removal and color-correction</title>
|
|
<h1>Dust-removal and color-correction</h1>
|
|
<b>Andreas Rick</b> (<a href="mailto:rickand@gemse.fr"><i>rickand@gemse.fr</i></a>)<br>
|
|
<i>Thu, 05 Aug 1999 09:11:10 +0200</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#61">[ date ]</a><a href="index.html#61">[ thread ]</a><a href="subject.html#61">[ subject ]</a><a href="author.html#61">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0062.html">Andreas: "Autofocus problem with Coolscan LS-30 backend"</a>
|
|
<li> <b>Previous message:</b> <a href="0060.html">Lee Bartolotti: "Re: Microtek ScanMaker V6USL"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0065.html">Ewald R. de Wit: "Re: Dust-removal and color-correction"</a>
|
|
<li> <b>Reply:</b> <a href="0065.html">Ewald R. de Wit: "Re: Dust-removal and color-correction"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
"Ewald R. de Wit" wrote:<br>
|
|
<i>> </i><br>
|
|
<i>> Andreas Rick (<a href="mailto:rickand@gemse.fr">rickand@gemse.fr</a>) wrote:</i><br>
|
|
<i>> </i><br>
|
|
<i>> > Unless you scan with the maximal resolution (10/12 bit) and no LUT,</i><br>
|
|
<i>> > you cannot easlily reconstruct the dust-image from the</i><br>
|
|
<i>> > infrared channel . That'a why I think the conversion from Inrared</i><br>
|
|
<i>> > to "dust" should be done by the backend. It is a very scanner</i><br>
|
|
<i>> > dependent operation as it depends a lot on the</i><br>
|
|
<i>> > light source and CCD sensitivity for the different wavelengths.</i><br>
|
|
<i>> </i><br>
|
|
<i>> The algorithm is not scanner dependent at all. Only the parameters</i><br>
|
|
<i>> vary (but they vary with filmtype too). I still think it's possible</i><br>
|
|
<i>> that the parameters can be autoguessed by minimizing some sort of</i><br>
|
|
<i>> correlation between the channels. You have access to a few million</i><br>
|
|
<i>> data points, so what would stop you.</i><br>
|
|
<p>
|
|
That's what I ment when I said:<br>
|
|
"I am thinking of a method but it makes a lot of assumptions <br>
|
|
on the image content."<br>
|
|
You actually assume that you can get the correction values<br>
|
|
from the image data. If the color space is not very well<br>
|
|
filled by your example image you may get strange effects.<br>
|
|
If you know that there is no LUT applied you only need to<br>
|
|
estimate the 4*4 matrix (or at least the 4 values for the IRED). <br>
|
|
If there are LUTs applied you have to find out the LUTs too. <br>
|
|
I haven't tried it, but I guess it is pretty tough<br>
|
|
to estimate the LUTs only from the supposed correlation<br>
|
|
values. If the colors are not equally distributed you may<br>
|
|
get strange results.<br>
|
|
<p>
|
|
I hope the calculation time for the color space correction<br>
|
|
is sufficient low that we can do it faster than the<br>
|
|
scanning so will not slow it down.<br>
|
|
<p>
|
|
<i>> > Maybe I'll add a raw format option that writes all data</i><br>
|
|
<i>> > without transformation to a 64Bit image (4*16) to</i><br>
|
|
<i>> > be used by a program that can do the Coolscan specific dust-removal</i><br>
|
|
<i>> > and which can apply the LUT afterwards.</i><br>
|
|
<i>> </i><br>
|
|
<i>> I'd be much obliged, this is exactly what I want.</i><br>
|
|
<i>> </i><br>
|
|
<i>> > This type of data-flow is basically optimized for speed - meaning</i><br>
|
|
<i>> > you don't have to wait on the scanner and the scanner doesnt</i><br>
|
|
<i>> > have to wait for the dust removal -</i><br>
|
|
<i>> </i><br>
|
|
<i>> My upcoming new frontend does all processing on the fly with priority</i><br>
|
|
<i>> to reading the scan data, meaning both scanner and CPU will work at</i><br>
|
|
<i>> full speed. This would be another reason to at least have the option</i><br>
|
|
<i>> to do defect removal in the frontend.</i><br>
|
|
<p>
|
|
Can (or will) your programm read 16*3 Bit color images,<br>
|
|
display them, allow the application of a LUT and save the resulting<br>
|
|
image to a 8-Bit file? <br>
|
|
<p>
|
|
You don't actually have to do the processing in the frontend<br>
|
|
to get the CPU and scanner working at full speed, it is<br>
|
|
also possible inside the backend.<br>
|
|
I will try to use the scsi_request... stuff to parallelize<br>
|
|
scanning and infrared-correction.<br>
|
|
<p>
|
|
<i>> </i><br>
|
|
<i>> > it is not because I hope</i><br>
|
|
<i>> > there will be a general way to treat these images.</i><br>
|
|
<i>> </i><br>
|
|
<i>> I gather you haven't had too much luck with it yet but damnit it must</i><br>
|
|
<i>> be possible!</i><br>
|
|
<p>
|
|
I will continue implementing the color correction and the dust-removal<br>
|
|
in the backend (and in a plugin). <br>
|
|
When it is done and we find another scanner that makes<br>
|
|
use of it, we can easily extract it and move it to a frontend.<br>
|
|
<p>
|
|
<i>> </i><br>
|
|
<i>> > While the 4*4 transformation can be done "on the fly" pixel per pixel</i><br>
|
|
<i>> > without having all the image available, the dustremoval needs</i><br>
|
|
<i>> > the whole image (or parts of it) to do spacial interpolation.</i><br>
|
|
<i>> </i><br>
|
|
<i>> You don't really need the whole image, a few scanlines are sufficient</i><br>
|
|
<i>> to do the interpolation (I have done this once). So it is possible to</i><br>
|
|
<i>> do on the fly too. You just use already interpolated pixels for</i><br>
|
|
<i>> interpolating the lower defects.</i><br>
|
|
<p>
|
|
If we know our thresholds and parameters all in advance we can actually<br>
|
|
do the interpolation on a smaller region.<br>
|
|
But if we want to estimate all the correction values (as you suggested above)<br>
|
|
then we need a max of image statistics and we better get the whole image.<br>
|
|
My current dust-removal plugin only uses a small region to interpolate,<br>
|
|
but I will need to do some refinement to treat overlapping regions so<br>
|
|
that occluded pixels at the borders of that regions can be interpolated<br>
|
|
correctly.<br>
|
|
<p>
|
|
Greetings from Paris<br>
|
|
<p>
|
|
Andreas<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0062.html">Andreas: "Autofocus problem with Coolscan LS-30 backend"</a>
|
|
<li> <b>Previous message:</b> <a href="0060.html">Lee Bartolotti: "Re: Microtek ScanMaker V6USL"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0065.html">Ewald R. de Wit: "Re: Dust-removal and color-correction"</a>
|
|
<li> <b>Reply:</b> <a href="0065.html">Ewald R. de Wit: "Re: Dust-removal and color-correction"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|