kopia lustrzana https://gitlab.com/sane-project/website
146 wiersze
7.3 KiB
HTML
146 wiersze
7.3 KiB
HTML
<!-- received="Wed Aug 4 03:28:07 1999 PDT" -->
|
|
<!-- sent="Wed, 04 Aug 1999 12:25:55 +0200" -->
|
|
<!-- name="Andreas Rick" -->
|
|
<!-- email="rickand@gemse.fr" -->
|
|
<!-- subject="Re: SANE_FRAME Formats" -->
|
|
<!-- id="37A81533.50A73A0E@gemse.fr" -->
|
|
<!-- inreplyto="SANE_FRAME Formats" -->
|
|
<title>sane-devel: Re: SANE_FRAME Formats</title>
|
|
<h1>Re: SANE_FRAME Formats</h1>
|
|
<b>Andreas Rick</b> (<a href="mailto:rickand@gemse.fr"><i>rickand@gemse.fr</i></a>)<br>
|
|
<i>Wed, 04 Aug 1999 12:25:55 +0200</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#51">[ date ]</a><a href="index.html#51">[ thread ]</a><a href="subject.html#51">[ subject ]</a><a href="author.html#51">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0052.html">Tom Martone: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
|
<li> <b>Previous message:</b> <a href="0050.html">Ewald R. de Wit: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0056.html">Ewald R. de Wit: "Re: SANE_FRAME Formats"</a>
|
|
<li> <b>Reply:</b> <a href="0056.html">Ewald R. de Wit: "Re: SANE_FRAME Formats"</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>> > I just want to tell it: Here come 4 channels, the first 3 are</i><br>
|
|
<i>> > RGB (which you may use for preview or other stuff)</i><br>
|
|
<i>> > and the last one is something I want to be able to save</i><br>
|
|
<i>> > as alpha channel to png or to gimp.</i><br>
|
|
<i>> </i><br>
|
|
<i>> Ok, this would make sense for someone who is experimenting with</i><br>
|
|
<i>> SANE.</i><br>
|
|
<i>> </i><br>
|
|
<i>> > I have no objections to add</i><br>
|
|
<i>> > SANE_FRAME_G3</i><br>
|
|
<i>> > SANE_FRAME_G4</i><br>
|
|
<i>> > SANE_FRAME_JFIF</i><br>
|
|
<i>> > SANE_FRAME_RGBI</i><br>
|
|
<i>> > SANE_FRAME_TEXT</i><br>
|
|
<i>> > and anything you want , but I would like to see at least:</i><br>
|
|
<i>> > SANE_FRAME_RAW</i><br>
|
|
<i>> > SANE_FRAME_RGBA</i><br>
|
|
<i>> > too.</i><br>
|
|
<i>> </i><br>
|
|
<i>> Ok, I have no problems to the last two but I feel they should be</i><br>
|
|
<i>> avoided in widespread production code. I.e, they should be more</i><br>
|
|
<i>> intended for experimenting and custom modifications.</i><br>
|
|
<p>
|
|
If we ever find out what is an "infrared" channel I am glad<br>
|
|
to rename the images back to SANE_FRAME_RGBI.<br>
|
|
<p>
|
|
<i>> > Right now the only link of the 4th channel of a Coolscan scanned</i><br>
|
|
<i>> > image to "infrared" is that it has been scanned with an infrared LED as light</i><br>
|
|
<i>> > source. After that I'm doing all kinds of transformation on it</i><br>
|
|
<i>> > which mix R,G,B and I (and I will do even more in the future)</i><br>
|
|
<i>> > to make it show only the dust in the image, and not the</i><br>
|
|
<i>> > color information. That is to say: when you get the 4th channel</i><br>
|
|
<i>> > out of the backend it is no longer an "infrared" image but a</i><br>
|
|
<i>> > "dust" image, so we might as well define SANE_FRAME_RGBD(ust).</i><br>
|
|
<i>> </i><br>
|
|
<i>> I hope it can still output the pure RGBI as well.</i><br>
|
|
<p>
|
|
I don't see much point in sending out the "infrared" channel.<br>
|
|
This opens so much questions with no reasonable answers:<br>
|
|
What LUT should I apply? <br>
|
|
Should I invert it if I scan negatives?<br>
|
|
...<br>
|
|
As there is no use of an infrared channel so far -other<br>
|
|
than dust removal- it is difficult to imagine what to do<br>
|
|
with it.<br>
|
|
Once you have converted the RGB channels with the user-gamma-LUT<br>
|
|
there is almost no way to use the infrared channel for dust-removal.<br>
|
|
(actually, I am thinking of a method but it makes a lot of assumptions <br>
|
|
on the image content)<br>
|
|
Unless you scan with the maximal resolution (10/12 bit) and no LUT,<br>
|
|
you cannot easlily reconstruct the dust-image from the<br>
|
|
infrared channel . That'a why I think the conversion from Inrared<br>
|
|
to "dust" should be done by the backend. It is a very scanner<br>
|
|
dependent operation as it depends a lot on the<br>
|
|
light source and CCD sensitivity for the different wavelengths.<br>
|
|
<p>
|
|
Maybe I'll add a raw format option that writes all data<br>
|
|
without transformation to a 64Bit image (4*16) to<br>
|
|
be used by a program that can do the Coolscan specific dust-removal<br>
|
|
and which can apply the LUT afterwards.<br>
|
|
This type of data-flow is basically optimized for speed - meaning<br>
|
|
you don't have to wait on the scanner and the scanner doesnt<br>
|
|
have to wait for the dust removal - it is not because I hope<br>
|
|
there will be a general way to treat these images.<br>
|
|
<p>
|
|
<i>> Just curious, but why would your production code do the 4x4 color</i><br>
|
|
<i>> transform in the backend, and the defect interpolation elsewhere?</i><br>
|
|
<i>> It would seem more logical to do it in the same place.</i><br>
|
|
<p>
|
|
Not so much. The dust removal can be done on the image with the<br>
|
|
gamma-LUT applied (and therefore on a 8 bit image)<br>
|
|
but not the 4*4 transformation.<br>
|
|
For the 4*4 transformation we need the "raw" values<br>
|
|
of the scanned image because we know how to transform them,<br>
|
|
which is no longer the case if the user has applied a LUT.<br>
|
|
While the 4*4 transformation can be done "on the fly" pixel per pixel<br>
|
|
without having all the image available, the dustremoval needs <br>
|
|
the whole image (or parts of it) to do spacial interpolation. <br>
|
|
Unless I store the whole image in the backend,<br>
|
|
dustremoval inside the backend is not optimal.<br>
|
|
I guess the 4*4 transform is what they call "Color Managment" in<br>
|
|
the TWAIN backend. It may be interesting even for RGB scanning.<br>
|
|
<p>
|
|
I am right now investigating the idea to do everything inside the<br>
|
|
backend (including dust-removal) but this requires up to 80 MB<br>
|
|
of memory.<br>
|
|
<br>
|
|
<i>> As more manufacturers will take a licence on Digital ICE, we can</i><br>
|
|
<i>> expect more scanners that have an IR channel. Therefore, at some point</i><br>
|
|
<i>> in time, it will make sense to do the defect removal in the frontend</i><br>
|
|
<i>> instead of in all the backends and a SANE_FRAME_RGBI will be essential.</i><br>
|
|
<p>
|
|
I just don't believe there will be an infrared channel that is<br>
|
|
suffiently standard that a dust-removal algorithm can work with it,<br>
|
|
unless it is already transformed to a "dust" image.<br>
|
|
The raw infrared channel is too much mixed with the red channel<br>
|
|
to be usefull.<br>
|
|
<br>
|
|
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="0052.html">Tom Martone: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
|
<li> <b>Previous message:</b> <a href="0050.html">Ewald R. de Wit: "Re: SANE_FRAME Formats (was Re: xsane-0.31 available)"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0056.html">Ewald R. de Wit: "Re: SANE_FRAME Formats"</a>
|
|
<li> <b>Reply:</b> <a href="0056.html">Ewald R. de Wit: "Re: SANE_FRAME Formats"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|