[sane-devel] New hardware report, patches: Canon PIXMA MX920/MX922, pixma_mp150.c
human2013odd at icebubble.org
human2013odd at icebubble.org
Wed Oct 23 19:04:17 UTC 2013
:scanner: Canon PIXMA MX922 Wireless-Print-Scan-Copy-Fax
:identified: CANON Canon PIXMA MX920 Series multi-function peripheral
:vendor: 0x04a9 [Canon]
:product: 0x176b [MX920 series]
:backend: pixma
:subdriver: mp150
:repository: git://anonscm.debian.org/sane/sane-backends.git
:commit: 0f23fb3fc19880361d62d1ec894472a1cc5a3af4
:tester: human
:date: 2013-10-23
Observations
============
Scanning from the flatbed over USB at 75, 150, 300, and 600 dpi
---------------------------------------------------------------
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?
No JPEG artifacts are visible in the scans. JPEG compression, which
some scanners use to speed-up scanning, probably isn't used by this
scanner.
The manufacturer's specifications list the maximum scan width as 8.5
inches. The source code lists the maximum scanning width as 638 pixels
at 75 dpi. That's 8.5066 inches. In reality, at these resolutions, the
scanner is capable of slightly wider scans. The maximum scan widths
are: 640px at 75dpi 1280px at 150dpi 2560px at 300dpi 5120px at 600dpi. That's
8.5333 inches, or 21.67 cm. You'll notice that the widths are all
640*2^n pixels.
The subdriver code specifies maximum scan height as 877px at 75dpi. That's
11.6933 inches, or 29.70 cm. Scans are confirmed to work up to this
limit: 877px at 75dpi, 1754px at 150dpi, 3508px at 300dpi, and 7016px at 600dpi. In
order to avoid damaging the scanner, I did not attempt to exceed this
limit.
Scanning from the flatbed over USB at 1200 and 2400 dpi
---------------------------------------------------------------
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.
Maximum scan widths are slightly less at these resolutions:
10208px at 1200dpi and 20416px at 2400dpi. (That's 8.5066 inches, or 21.61
cm.) I'm not sure if that's a limitation of the scanner at these
resolutions, or if it's due to rounding code in the backend. The
scanning width of 8.5066 inches is equivalent to the 638px at 75dpi
currently specified in the code.
Scans at these resolutions also work up to the subdriver-specified
maximum scan height: 14032px at 1200dpi and 28064px at 2400dpi. If you plan
to scan a full page at 2400 dpi, you may want to go get a cup of coffee.
It takes a while. :)
Scanning from the ADF over USB
---------------------------------------------------------------
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.
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.
Scanning over BJNP
---------------------------------------------------------------
Scanning over BJNP was tested, but not as thoroughly as scanning over
USB. Scanning from the flatbed works at all resolutions, but exhibits
exactly the same color shifting as when scanning over USB.
Scanning from the ADF works in both simplex and duplex, for single pages
and for multiple pages. Alas, the scanner still becomes unresponsive
after the last page is scanned. Subsequent attempts to scan return the
error "bjnp_open_tcp: Can not connect to scanner: Connection refused".
Scanning to USB MSD
---------------------------------------------------------------
Besides USB client and Ethernet ports, this scanner also has a USB host
port. The scanner can save images directly to a USB MSD (i.e., a
thumbdrive) plugged into the USB host port, without using a computer.
When scanning to USB MSD, however, only a subset of the scanner's image
settings are available. It will not let you scan to TIFF, but will let
you scan to JPEG, PDF, or Compact PDF. Only 150, 300, and 600 dpi can
be used.
Scanning is permitted in either "Document" mode or "Photo" mode.
"Photo" mode produces a more true image (white paper appears the typical
off-white gray), while "Document" mode produces images more suitable for
printing (i.e., with whiter whites). When scanning to JPEG format,
lossless compression isn't used. It doesn't even use quality 100.
Lossy compression is used, whether scanning to JPEG, PDF, or Compact
PDF. When scanning to JPEG in "Document" mode, JPEG artifacts are just
barely visible. The JPEGs and PDFs produced in "Photo" mode are of
higher quality, and the files are correspondigly a bit larger, than in
"Document" mode. Lossy compression is still used, however, whether in
or "Photo" mode or "Document" mode. Of the three available formats,
Compact PDF is the most lossy, but results in the smallest file size.
Compact PDF is only available in "Document" mode.
Interestinlgy, scans made to USB MSD do NOT exhibit the color shifting
observed when scanning to a computer over USB.
Error Recovery
------------------------------------------------------
Recovery from error conditions is unreliable. It is unknown whether
this is due to the backend or the frontends being used. Performing a
scan using the command-line tool scanimage often (but not always) makes
the scanner accessible again.
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. :-/
Patches
=======
tidy calc_shifting in backend/pixma_mp150.c::
diff --git a/backend/pixma_mp150.c b/backend/pixma_mp150.c
index e2af7dd..c52bb1e 100644
--- a/backend/pixma_mp150.c
+++ b/backend/pixma_mp150.c
@@ -623,10 +623,14 @@ calc_shifting (pixma_t * s)
/* If stripes shift needed (CCD devices), how many pixels shift */
mp->stripe_shift = 0;
+ /* If color plane shift (CCD devices), how many pixels shift */
+ mp->color_shift = mp->shift[0] = mp->shift[1] = mp->shift[2] = 0;
+
switch (s->cfg->pid)
{
case MP800_PID:
case MP800R_PID:
+ case MP830_PID:
if (s->param->xdpi == 2400)
{
if (is_scanning_from_tpu(s))
@@ -634,35 +638,15 @@ calc_shifting (pixma_t * s)
else
mp->stripe_shift = 3;
}
- break;
-
- case MP830_PID:
- if (s->param->xdpi == 2400)
- {
- if (is_scanning_from_tpu(s))
- mp->stripe_shift = 6;
- else
- mp->stripe_shift = 3;
- }
- break;
-
- default: /* Default, and all CIS devices */
- break;
- }
- /* If color plane shift (CCD devices), how many pixels shift */
- mp->color_shift = mp->shift[0] = mp->shift[1] = mp->shift[2] = 0;
- if (s->param->ydpi > 75)
- {
- switch (s->cfg->pid)
- {
- case MP800_PID:
- case MP800R_PID:
- case MP830_PID:
+ if (s->param->ydpi > 75)
+ {
mp->color_shift = s->param->ydpi / ((s->param->ydpi < 1200) ? 150 : 75);
if (is_scanning_from_tpu (s))
mp->color_shift = s->param->ydpi / 75;
+ /* If you're trying to decipher this color-shifting code,
+ the following line is where the magic is revealed. */
mp->shift[1] = mp->color_shift * get_cis_ccd_line_size (s);
if (is_scanning_from_adf (s))
{ /* ADF */
@@ -674,11 +658,11 @@ calc_shifting (pixma_t * s)
mp->shift[0] = 2 * mp->shift[1];
mp->shift[2] = 0;
}
- break;
+ }
+ break;
- default:
- break;
- }
+ default: /* Default, and all CIS devices */
+ break;
}
return (2 * mp->color_shift + mp->stripe_shift);
}
fix vertical stripes in scans at 1200 and 2400 dpi for MX920_PID by
bypassing reorder_pixels in post_process_image_data in
backend/pixma_mp150.c::
diff --git a/backend/pixma_mp150.c b/backend/pixma_mp150.c
index c52bb1e..2f887b6 100644
--- a/backend/pixma_mp150.c
+++ b/backend/pixma_mp150.c
@@ -1113,6 +1113,7 @@ post_process_image_data (pixma_t * s, pixma_imagebuf_t * ib)
&& s->cfg->pid != MX360_PID
&& s->cfg->pid != MX370_PID
&& s->cfg->pid != MX890_PID
+ && s->cfg->pid != MX920_PID
&& s->cfg->pid != MG3100_PID
&& s->cfg->pid != MG2100_PID
&& s->cfg->pid != MG5300_PID
increase maximum scan height for MX920_PID ADF in
backend/pixma_mp150.c::
diff --git a/backend/pixma_mp150.c b/backend/pixma_mp150.c
index 2f887b6..a2ac9c1 100644
--- a/backend/pixma_mp150.c
+++ b/backend/pixma_mp150.c
@@ -1271,6 +1271,7 @@ mp150_check_param (pixma_t * s, pixma_scan_param_t * sp)
s->cfg->pid == MX360_PID ||
s->cfg->pid == MX410_PID ||
s->cfg->pid == MX420_PID ||
+ s->cfg->pid == MX920_PID ||
s->cfg->pid == MX7600_PID )
&&
sp->source == PIXMA_SOURCE_FLATBED)
@@ -1724,7 +1725,7 @@ const pixma_config_t pixma_mp150_devices[] = {
DEVICE ("Canon PIXMA MX450 Series", "MX450", MX450_PID, 1200, 0, 0, 638, 877, PIXMA_CAP_CIS | PIXMA_CAP_ADF),
DEVICE ("Canon PIXMA MX520 Series", "MX520", MX520_PID, 1200, 0, 0, 638, 877, PIXMA_CAP_CIS | PIXMA_CAP_ADF),
DEVICE ("Canon PIXMA MX720 Series", "MX720", MX720_PID, 2400, 0, 0, 638, 877, PIXMA_CAP_CIS | PIXMA_CAP_ADF),
- DEVICE ("Canon PIXMA MX920 Series", "MX920", MX920_PID, 2400, 0, 600, 638, 877, PIXMA_CAP_CIS | PIXMA_CAP_ADFDUP),
+ DEVICE ("Canon PIXMA MX920 Series", "MX920", MX920_PID, 2400, 0, 600, 638, 1155, PIXMA_CAP_CIS | PIXMA_CAP_ADFDUP),
END_OF_DEVICE_LIST
};
I'm also making the above patches available by git:
https://bitbucket.org/Smiley/sane-backends.git
Document Format
===============
This report is written in reStructuredText_, in order to facilitate its
use in multiple contexts, such as e-mail, WWW, PDF, or processing using
command-line text utilities.
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E150.png
Type: image/png
Size: 804 bytes
Desc: color bleeding
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20131023/4290ec70/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1200.png
Type: image/png
Size: 1634 bytes
Desc: stripes at 1200 dpi
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20131023/4290ec70/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2400.png
Type: image/png
Size: 20689 bytes
Desc: stripes at 2400 dpi
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20131023/4290ec70/attachment-0005.png>
More information about the sane-devel
mailing list