[sane-devel] maximum image size for a scan for Canon pixma backend

Fri Dec 31 13:32:22 UTC 2010

Le vendredi 31 décembre 2010 à 14:11 +0900, Gernot Hassenpflug a écrit :
> On Fri, Dec 31, 2010 at 8:11 AM, Gernot Hassenpflug
> <aikishugyo at gmail.com> wrote:
> > On Fri, Dec 31, 2010 at 8:05 AM, Nicolas Martin
> > <nicolas0martin at gmail.com> wrote:
> >> Le vendredi 31 décembre 2010 à 02:55 +0900, Gernot Hassenpflug a écrit :
> >>> On Fri, Dec 31, 2010 at 2:50 AM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> >>> > On Fri, 31 Dec 2010 02:41:10 +0900, Gernot Hassenpflug wrote:
> >>> >> On Fri, Dec 31, 2010 at 2:19 AM, Gerard Klaver <gerard.klaver at xs4all.nl> wrote:
> >>> >>> On Fri, 2010-12-31 at 01:29 +0900, Gernot Hassenpflug wrote:
> >>> >>>> Dear all,
> >>> >>>> I have been involved in trying to support the Canoscan 9000F, and the
> >>> >>>> testing community has grown to about 15 individuals. A few of them
> >>> >>>> have programming knowledge and tonight one individual send in
> >>> >>>> corrected code to handle the final hurdle: correctly aligning the
> >>> >>>> sub-images in the 9600dpi TPU mode. So the scanner is now supported
> >>> >>>> for all modes.
> >>> >>>>
> >>> >>>> However, for large images at both 4800dpi and 9600dpi modes, it seems
> >>> >>>> the max size of the image is limited in some way, so that only a
> >>> >>>> section of the desired image is delivered. Is this something that can
> >>> >>>> be set in the individual driver files (like pixma_mp150.c) or in some
> >>> >>>> of the generic pixma driver .c or .h files (which I do not want to
> >>> >>>> touch if possible)? I don't see a problem in the linesize or
> >>> >>>> dimensions, only in the image_size value seen by [pixma] debugging
> >>> >>>> output.
> >>> >>>>
> >>> >>>> Best regards,
> >>> >>>> Gernot Hassenpflug
> >>> >>>>
> >>> >>>> --
> >>> >>>> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> >>> >>>> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> >>> >>>> Unsubscribe: Send mail with subject "unsubscribe your_password"
> >>> >>>>              to sane-devel-request at lists.alioth.debian.org
> >>> >>>
> >>> >>> One possible solution (if not yet done), is to check the declaration of
> >>> >>> the  image_size parameter, for a 9600 dpi A4 scan (color) size is about
> >>> >>> 550 000 000 000 bytes. (long long is needed)
> >>> >>
> >>> >> Hi, thank you for that. I see that image_size is currently declared as
> >>> >> "unsigned". I imagine that changing the declaration will need to be
> >>> >> checked in all places where the calculations using image_size are
> >>> >> done, or not?
> >>> >>
> >>> >> Currently, from the report I obtain from a test user, a 4800x4800dpi image with
> >>> >>
> >>> >> dimensions: 32824 px (width) * 47248 px (height)
> >>> >>
> >>> >> should have a image_size of 4652605056 bytes (W*H*3 for channel number)
> >>> >>
> >>> >> whereas the actual image_size used is 357637760 bytes (approximately
> >>> >> 341.1 MiB). I am still trying to ascertain whether for some reason the
> >>> >> wrong calculation for image_size might have been made, but certainly
> >>> >> the width and height are correctly there.
> >>> >
> >>> > 32824 * 47248 * 3 - 357637760 = 4294967296
> >>> >
> >>> > which is exactly 2^32.  So that suggests exactly the problem described
> >>> > above.
> >>>
> >>> Ah! I suspected it was that, but forgot I had to take the difference
> >>> to get this number. Fantastic! Well, that sounds like somewhat of a
> >>> issue then for the SANE Canon maintainer to comment on. I guess this
> >>> issue had to come up eventually.
> >>
> >> Should be possible to extend the image size in pixma backend by
> >> declaring uint64_t instead of unsigned the following variables:
> >>
> >> image_byte_read (in pixma.c),
> >> image_size (in pixma.h)
> >> cur_image_size (in pixma_common.h)
> >>
> >> Debug statements should also to be adjusted, %llu instead of %u in the
> >> different format strings, although this gives a compilation warning
> >> anyway, as the gcc compile statement uses the -pedantic flag.
> >>
> >> Unless someone has a better solution for sprintf 64 bits integers ?
> >>
> >> Anyway, could you give a try on 9000F with those changes ?
> >
> > Hi Nicolas,
> > Thanks, I'll implement that and send away for testing (I do not have
> > the scanner myself), and report back.
> 
> Dear all,
> 
> It seems that fix has not broken anything yet (stil awaiting results
> from testers on how large images go). However, I have a report from a
> tester that might be of interest:
> 
> "I also replaced a memcpy() by a memmove() because the areas are
> overlapping. The spec says that memcpy should not be used for
> overlapping regions, and in recent glibc versions code relying on this
> behaviour doesn't work any more. (Valgrind reported this.)"
> 
> This is the line near the end of  the post_process_image_data funtion
> in pixma_mp150.c:
> 
> 	  /* Crop line to selected borders */
> 	  memmove(cptr, sptr + cx, cw);
> 
> I have this in my code now, and it seems not to break my scans with
> MP460, MP960, MP810, CS8800F. Nicolas, do you have a comment on this?

This line is also part of the crop enhancement code proposed, that was
committed in January. Yet, I did not investigate deeply how it works,
but the memmove in this case is certainly better if zones overlap,
although I did not notice any problems by myself with memcpy. 

So I'll change this statement to memmove.

One point is that overlapping should not occur here, as line buffer
sizes in post_process_image_data() should be large enough to not overlap
when rearranging the pixels. If overlap occurs with this statement, this
is potentially another buggy area ...

Nicolas