[sane-devel] Kodak ESP all in one scan data format?

[m. allan noah]

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>