What I always do is write RGB in the upper left corner of a piece of white paper (each letter in the correct color). Then I get logs of small, low resolution color and gray scans of that corner, using the windows driver and this software:
http://www.pcausa.com/Utilities/UsbSnoop/ Then I cat the resulting logs thru the attached perl script. After that, I stare at the data for awhile, and write another program that dumps out the image data blocks to a .pnm file. Then, I use vi to edit the header of the .pnm file, while viewing the file in gqview. gqview is smart enough to re-read the file when you save changes in vim. Sounds tedious, but honestly, this is my favorite part of the job, so I'd be happy to look at yours if you want. allan On Sun, Nov 21, 2010 at 9:14 AM, Paul Newall <p.newalls at ntlworld.com> wrote: > I would like to write a backend for this range of all in one printers. (I > have Kodak ESP 5250) > I have made some progress with the protocol and can?aquire a scan. > But It's not obvious how the data in the scan is organised. > Does anyone recognise it? > > The protocol has 8 byte commands, for example a scan request starts like > this > scanner is 192.168.1.2 port 9101 > 00000000? 1b 53 4c 00 00 00 00 00????????????????????????? .SL..... > //command L lock? from PC > ??? 00000000? 1b 53 53 00 02 00 00 00????????????????????????? .SS..... > //acknowledge S 00 02? from scanner > 00000008? 1b 53 46 00 00 00 00 00????????????????????????? .SF..... > //command F? from PC > ??? 00000008? 1b 53 53 00 02 00 00 00????????????????????????? .SS..... > //acknowledge S 00 02?? from scanner > > after?some more command / acknowledge exchanges the data starts > > ??? 00000058? ff ff fc d7 f2 bf c8 f3? 44 46 96 19 11 b6 a1 34 ........ > DF.....4 //data starts? (it always seems to start ff ff) > ??? 00000068? f2 53 a6 73 7a 99 96 e7? 24 ea e2 a3 44 c4 8c ce .S.sz... > $...D... > ??? 00000078? 6d cd e4 89 2b 6b b2 67? 2d f7 e8 5d 30 b9 f3 8e m...+k.g > -..]0... > ??? 00000088? 7a 82 7a 03 1c 26 34 d7? 67 9a 7a 2c 31 8b 12 b5 z.z..&4. > g.z,1... > ??? 00000098? ad 56 58 69 86 a7 5c 39? a8 df 4c f9 f9 f7 75 96 .VXi..\9 > ..L...u. > ??? 000000A8? 80 3d 33 59 56 55 96 b3? d3 a5 e7 84 63 a4 5b da .=3YVU.. > ....c.[. > ??? 000000B8? ae 6e 72 c3 9c ae 8a ad? cc b9 9b d7 7e 87 cb 9c .nr..... > ....~... > > I have tried scanning white paper, red paper,? and black paper with no > obvious pattern in the data. > It's possible that lines end with several 00 00 00 bytes and start with > several ff ff bytes. > Since there seems to be enough data for 4 bits per colour per pixel, and I'd > expect to see at least 8 bits per colour per pixel, I wonder if the data is > compressed slightly. > > Does anyone have an idea what format this data could be in? > What compression algorithms might have been used for scanner data? > Should I try to scan a particular pattern to help identify the format? > (maybe narrow vertical stripes?) > > > -- > 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 > -- "The truth is an offense, but not a sin" -------------- next part -------------- A non-text attachment was scrubbed... Name: spike4.pl Type: application/x-perl Size: 1818 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101121/c7f8bf21/attachment.bin>
