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

Sat Jan 1 00:49:20 UTC 2011

On Fri, Dec 31, 2010 at 10:32 PM, Nicolas Martin
<nicolas0martin at gmail.com> wrote:
> 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 ?

Happy new year to you all!

More changes were needed in pixma.c, pixma.h, pixma_common.c (as well
as those in pixma_common.h), and in pixma_mp150.c to handle the
calculations with uint64_t. Some more variables needed to be declared
as either uint64_t, or in one case as long instead of int.

I still need to follow through on those changes in pixma_mp750.c also.

I had a report that %lu might be better than %llu for the debug
statements, so I would like to confirm that %llu was not a typing
error? Should I use %llu or %lu for the debug statements when uint64_t
is the declared type?

>> 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 ...

Thanks for that information.

Regards,
Gernot