Re: [sane-devel] MX375 no recovery from ADF empty when scan started

2014-05-23 Thread Rolf Bensch
Hi Matthias,

Please try attached patch. It is based on patch1-new.

Again I need a log file created with 'export SANE_DEBUG_PIXMA=11'.

Cheers,
Rolf



Am 21.05.2014 22:33, schrieb Matthias Peter Walther:
 Sure. Zipped, cause they are larger than 100 KB.
 
 On 21.05.2014 21:44, Rolf Bensch wrote:
 Hi Matthias,

 Please create logfiles again with 'export SANE_DEBUG_PIXMA=11'.

 Many thanks.

 Cheers,
 Rolf


 Am 21.05.2014 20:53, schrieb Matthias Peter Walther:
 Hallo Rolf,

 one fixed, one to go.

 An empty ADF still crashes the device. But it starts scanning now, if I
 insert paper before the timeout runs out.

 I created logs for both issues.

 Grüße
 Matthias

 On 21.05.2014 17:27, Rolf Bensch wrote:
 Hi Matthias,

 I created a new patch1. This should fix both issues. I also added a new
 debug output to check paper empty code.

 Cheers,
 Rolf


 Am 21.05.2014 09:51, schrieb Matthias Peter Walther:
 Hallo Rolf,

 I can't notice any change of behavior here. To make sure, that I use the
 patched version, I manually deleted all libsane*.

 See log attached.

 And the scan does not start, if I insert paper during the timeout
 countdown. The scanner beeps, so the firmware detects the inserted
 paper. But the scan does not start.

 Grüße
 Matthias

 On 20.05.2014 22:44, Rolf Bensch wrote:
 Hi Matthias,

 Am 20.05.2014 17:49, schrieb Matthias Peter Walther:
 Hallo Rolf,

 sorry to bother you again. But here is another bug with my MX375.
 No problem.

 If I start an ADF-scan while the ADF is empty, the scanner does not
 recover and needs to be restarted by hand.
 Attached patch should fix this. The patch is based on recent git code.

 [...]

 I mean scanning ADF without paper in it is stupid, but it should not
 crash the device :)
 It's not stupid. Maybe you started the job and forgot to put the paper
 into the ADF. Then the job should start scanning if you put the paper
 into the ADF *before* timeout counted down to 0 and aborts the job.

 Please test, if scanning starts if you put paper into the ADF during
 timeout counts down.

 Cheers,
 Rolf
 
--- ./pixma_mp150.c 2014-05-23 20:02:28.0 +0200
+++ ../sane-backends/backend/pixma_mp150.c  2014-05-23 20:17:41.0 
+0200
@@ -1361,6 +1361,10 @@
   if (!has_paper (s))
   {
 PDBG (pixma_dbg (4, *mp150_scan* no paper in ADF *\n));
+error = abort_session (s);
+if (error  0)
+  PDBG (pixma_dbg (1, WARNING:abort_session() failed %d\n, error));
+
 if (mp-generation == 4  mp-adf_state == state_idle)
   {
 if (!send_xml_dialog (s, XML_END))
-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org

Re: [sane-devel] HP Scanjet 3670 bad colors

2014-05-23 Thread Stef

On 20/05/2014 18:42, Octavio Alvarez wrote:

On 05/20/2014 12:27 AM, Octavio Alvarez wrote:

So far, I have repeated some of the tests with scanimage only and
target_code seems to be too high for my taste. 0x8000 seems like a lot
better value. I'm still testing though.

Hi, Stef. I have made some tests using scanimage only. I, effectively,
don't get the artifacts anymore. Thanks a lot! However, you were right,
the image quality has problems.

Using target_code = 0xe000, the currently coded value, I get a bluish
and saturated image. I tried lowering target_code across multiple values
down to 0x4000. The lower the value, the better the quality but the
darker the image.

At 0xb000, the horizontal extremes of the image are white balanced but
it is still noticeably bluish towards the center. This is, two small
vertical correctly white-balanced sections are noticed at the left and
right extremes.

For example, at 0x8000, the image is not saturated anymore, and the
image is way better white-balanced overall. However, the image is
noticeably darker image (75% of the histogram with typical white at 55%
luminosity). There is still a noticeably vertical stripe towards the
blue, a bit off the center towards the right.

At 0x4000, I don't get bluish stripes and perfect white-balance, but it
results in only half of the histogram.

I tried tweaking the o value (offset?) but I didn't seem to find any
kind of pattern, except that if I set it too high I get badly colored
stripes, so I just left them at their original values.

Thanks again.

Hello,

the offset shouldn't be touched. For some undocumented reason the 
ASIC needs it to have the shading coefficients match the right pixels.


target_code is giving the desired target value for white. Once this 
value is correct : not too low, and not too high to avoid 
solarization, you should turn to tuning gamma values. They are defined 
in genesys_devices.c for the CCD_HP3670. Currently it is 1.0 for each 
color channels, and this need to be adjusted. This will improve the 
histogram.


Regards,
Stef

--
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org