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
