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
