[sane-devel] New hardware report, patches: Canon PIXMA MX920/MX922, pixma_mp150.c

Rolf Bensch rolf at bensch-online.de
Mon Oct 28 15:44:34 UTC 2013


Many thanks for your detailled test report!


Am 23.10.2013 21:04, schrieb human2013odd at icebubble.org:
> Scanning works and produces useful results which appear mostly correct.
> There appears to be some color bleeding in the vertical direction.  With
> a black letter on white paper, this generally consists of a magenta hue
> just above the letter and a cyan hue just below it.  Attached, for
> example, is a blue letter "E" scanned at 150 dpi.  This bleeding effect
> diminishes as resolution increases, and is barely noticeable at 600 dpi
> or higher.  At 2400 dpi, the bleeding isn't visible to the eye, but it
> is still present, and can be detected using image manipulation software.
> I tried modifying the subdriver code in backend/pixma_mp150.c to shift
> the R/G/B color planes up/down the page, but could not get the colors to
> align.  It looks like the sensor consists of three rows, with red toward
> the top of the page, green in the middle, and blue towards the bottom of
> the page, but that the R/G/B sensors aren't positioned over the same
> physical spot on the page; when straddling the boundary between two
> colors, a false color is produced.  In theory, one could realign the
> color planes by scanning at 3x the desired resolution, shifting the
> colors, and then downsampling the result.  However, the resolutions
> supported by the scanner are all 75 * 2^n dpi.  Because 2 and 3 are
> relatively prime, this method can't be used to produce scans at any of
> the resolutions that the scanner offers.  So, either the sensor data
> from the scanner isn't being read correctly, or the scanner was designed
> by a team of masturbuitng monkeys with associates' degrees in French
> poetry.  I mean, really, who else would design a color scanner that
> produces inaccurate colors?
> 

Please check scanner's raw data with this patch:

--- ./pixma_mp150.c	2013-10-28 15:34:55.000000000 +0100
+++ ../sane-backends/backend/pixma_mp150.c	2013-10-28 16:03:30.000000000
+0100
@@ -1124,14 +1125,16 @@
           /* Color plane and stripes shift needed by e.g. CCD */
           /*PDBG (pixma_dbg (4, "*post_process_image_data*****
Processing with c=%u, n=%u, m=%u, w=%i, line_size=%u ***** \n",
 	        c, n, m, s->param->wx, line_size));*/
-          if (s->cfg->pid != MG5300_PID && s->cfg->pid != MG6300_PID &&
c >= 3)
+          if (0)
+          /* if (s->cfg->pid != MG5300_PID && s->cfg->pid != MG6300_PID
&& c >= 3) */
             dptr = shift_colors (dptr, sptr,
                                  s->param->wx, s->param->xdpi,
s->cfg->pid, c,
                                  mp->shift, mp->stripe_shift);

           /* special image format for *most* devices at high dpi.
            * MP220, MX360, MX370, MX890, MG5300 are exceptions */
-          if (n > 0
+          if (0)
+          /*  if (n > 0
               && s->cfg->pid != MP220_PID
               && s->cfg->pid != MX360_PID
               && s->cfg->pid != MX370_PID
@@ -1139,7 +1142,7 @@
               && s->cfg->pid != MG3100_PID
               && s->cfg->pid != MG2100_PID
               && s->cfg->pid != MG5300_PID
-              && s->cfg->pid != MG6300_PID)
+              && s->cfg->pid != MG6300_PID) */
               reorder_pixels (mp->linebuf, sptr, c, n, m, s->param->wx,
line_size);

           /* Crop line to selected borders */

With this patch you disable all post processing functions. Please check
vertical and horizontal colour shift. Maybe we'll need to add some
special shift handling for this scanner.


> 
> Scanning worked but produced images with vertical stripes.  Attached are
> examples of this phenomenon at 1200 and 2400 dpi.  This problem was
> eliminated by bypassing the call to reorder_pixels in the
> post_process_image_data function of backend/pixma_mp150.c.  This fix is
> included in the patches supplied at the end of this report.
> 

I'll commit your patch later.


> 
> At 75, 150, 300, and 600 dpi, scans from the ADF have the same maximum
> widths as on the flatbed (640px at 75dpi, scaled by 2^n).  The subdriver
> currently limits scans from the ADF to the same maximum height as scans
> from the flatbed.  The nominal maximum page height usable in the ADF is
> 14.0 inches.  That would be 1050px at 75dpi.  However, this scanner's ADF
> can actually scan, in simplex, pages that are physically up to 15.5
> inches long.  I've managed to scan 1155px at 75dpi.  That's 15.4 inches, or
> 39.12 cm.  Accordingly, I've increased the height limit in the subdriver
> code to 1155px at 75dpi.  This fix is included in the patches supplied at
> the end of this report.
> 

I'll commit your patch later.


> Multiple one-sided pages can be scanned using the scanadf tool (the top
> page is scanned first), but after the last page is scanned, the scanner
> becomes unresponsive and scanadf eventually times-out.  Performing a
> scan using the command-line tool scanimage makes the scanner accessible
> again.
> 
> A single page of up to 12 inches in height can be scanned in duplex.
> The second side of the page appears upside down.  This also results in
> the scanner becoming unresponsive, as above.  Attempting a duplex scan
> of a page 13 inches long, or longer, causes the scanner to raise an
> error.
> 
> Multiple pages of up to 12 inches in height can also be scanned in
> duplex, but after the last page is scanned, the scanner becomes
> unresponsive, as above.
> 

There is a well known bug for ADF scans. If you like I can send you some
test code so that we can fix this issue. I have no ADF scanner to test
this by myself.

> 
> Untested
> ------------------------------------------------------
> 
> No attempt was made to try scans on the flatbed at resolutions above the
> subdriver-specified maximum resolution of 2400 dpi, scans from the ADF
> at resolutions above the subdriver-specified maximum resolution of 600
> dpi, or to scan the flatbed past the the subdriver-specified maximum
> image height.  I also did not test to see whether or not the maximum
> widths and heights of scans over BJNP were the same as over USB.  All
> the test scans I made were in color; no testing of grayscale or other
> modes was done.  It's presumed that, if you can scan in color, your
> color image could always be converted to grayscale.  Despite the
> scanner's flawed color sensor implementation (see above), grayscale
> scans should reflect accurate grayscale levels.  So, there you have it!
> A "color" scanner that can only accurately scan shades of gray.  :-/
> 

Scanning via BJNP should have the same behaviour as USB scans.

Grayscale and lineart are software modes and should run independent from
the scanner model.

> 
> Patches
> =======
> 
> tidy calc_shifting in backend/pixma_mp150.c::
> 

I asked another developer to check this patch with his scanner. After
his OK I'll also commit this to SANE git.

Your scanner should also button controlled. Please test this patch:

--- ./pixma_mp150.c	2013-10-28 15:34:55.000000000 +0100
+++ ../sane-backends/backend/pixma_mp150.c	2013-10-28 16:13:02.000000000
+0100
@@ -940,7 +940,8 @@
    * rr: scan resolution
    * poll event with 'scanimage -A' */
   if (s->cfg->pid == MG6200_PID
-      || s->cfg->pid == MG6300_PID)
+      || s->cfg->pid == MG6300_PID
+      || s->cfg->pid == MX920_PID)
   /* button no. in buf[7]
    * size in buf[10] 01=A4; 02=Letter; 08=10x15; 09=13x18; 0b=auto
    * format in buf[11] 01=JPEG; 02=TIFF; 03=PDF; 04=Kompakt-PDF

Connect your scanner via USB, enable debug output with 'export
SANE_DEBUG_PIXMA=11', press any button and request button status with
'scanimage -A'.

The response should contain similar lines:

  Buttons:
    --button-update
        Update button state
[pixma] INTR T=1.603 len=32
[pixma]  00000000:00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[pixma]  00000010:00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[pixma]
    --button-1 <int> [1] [read-only]
        Button 1
    --button-2 <int> [0] [read-only]
        Button 2
    --original <int> [0] [read-only]
        Type of original to scan
    --target <int> [2] [read-only]
        Target operation type
    --scan-resolution <int> [0] [read-only]
        Scan resolution

My scanner has less info than yours. Please read the source code and the
sane-pixma man page for detailled infos.

I'll commit all patches at once when stripe shift and button support
will be fixed.

Many thanks for your help.

Cheers,
Rolf



More information about the sane-devel mailing list