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

[Gernot Hassenpflug]

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.
Best regards,
Gernot Hassenpflug