[sane-devel] HP 5590 ADF end of page

[Protected]

Hello Ilia,

The test results on my end follow:

* Grayscale
End of page is marked by a 156,156,156 pixel.
End of document by a 255,255,255 one.
(By the way, the line with the EOP/EOD still belongs to the page.)

* Smaller page size
I tested with 10 cm x 10 cm, and also 1 cm x 10 cm. The pixel indicators
are present in both cases and have exactly the same values as they have
with the normal page sizes.

* Lineart
Things are a little different with this one. Using resolution 100, the
indicator bar was 2 px wide (instead of the usual 1 px); with 300, 6 px.
So it apparently scales that with the size or resolution of the image.

End of page is marked by alternating 255,255,255 and 0,0,0 pixels
(starting with the white ones).
End of document is marked by a row of 255,255,255 pixels.

Using the color or grayscale modes and a higher resolution does not
alter the width of the indicator bar as it happens with lineart.

Normal ADF and duplex have no apparent difference regarding the indicators.

By the way, the actual blue (or all channels in grayscale) value of the
indicator pixel marking the end of a page seems somewhat random. Rainer
reported 170 on his email a couple of days ago, and I observed the same
value on a couple of images I had scanned before. However, today I got
156 somehow. It would be probably best to check for a blue value between
1 and 254, programmatically speaking.

Best,

Augusto

Ilia Sotnikov wrote:
> Gentlemen,
> being author of the backend let me thank you for spotting the pixel
> behavior. As I mentioned somewhat earlier I discovered the duplex mode
> in original Windows driver occasionally. That means there some aspects
> to be discovered such as the pixel indicator one.
> 
> Meanwhile, let's account for most of use cases - can you please redo
> your experiments but with grayscale/BW modes? I'm wondering if there
> would be similar indicator and would interesting to see its value for
> both cases.
> 
> Also, we will still need to account for nearest paper size even with
> pixel indicator, otherwise scanner might drop the indicator if scan
> area is smaller than actual sheet. Another set of experiments would
> shed some light on this as well.
> 
> Finally, some frontends might require user to account for doubled
> count of output pages vs. fed ones (eg. Xsane if I remember
> correctly), some doing continuos operation should handle this well
> (eg. scanadf probably).
> 
> Hence, can you please conduct the following:
> - redo scanning with ADF duplex, same parameters as you did previously
> but with grayscale, and look for potential pixel indicator value?
> - same as previous attempt, but with BW?
> - same as first one but with paper size intentionally set smaller than
> sheet being fed?
> Then please report back your findings.
> 
> Unfortunately, I don't have access to the scanner model so will
> totally rely on your input.
> 
> ---
>  Ilia Sotnikov
> 
>> On Nov 8, 2014, at 15:03, Protected <spamme at modanese.net> wrote:
>>
>> Hello Rainer,
>>
>> I have actually discovered yet another trick with the blue pixels: the
>> pixel's blue RGB value is not random; in fact it even signals the end of
>> the document (170 when there are pages left to be scanned, and 255 at
>> the end of the document).
>>
>> In the meantime, I have also wrote a Perl script using ImageMagick to
>> crop the images properly. Still, it would be nice having the driver do
>> that automatically.
>>
>> ADF with 150 dpi does not look bad at all on my end.
>>
>> Best,
>>
>> Augusto
>>
>> Rainer Keller wrote:
>>> Hello Augusto,
>>>
>>> I tried to handle the blue pixel as a page change.
>>> Additional lines will be skipped until the blue pixel is found.
>>> But now the scanimage tool will not terminate properly, maybe because just
>>> skipping lines like I do is not the correct way to do this.
>>>
>>> See attached patch.
>>>
>>> Given the complexity of the sane code and limited spare time I tend more to
>>> write a new frontend  to handle the page change marker. It could then also
>>> handle the mirrored backsides.
>>>
>>> I tested it with duplex and 300 dpi.
>>>
>>> BTW, have you tried using the ADF with 150 dpi? For me the scanned images are
>>> all bad.
>>>
>>> - Rainer
>>
>> --
>> sane-devel mailing list: sane-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>>             to sane-devel-request at lists.alioth.debian.org
>