[sane-devel] compression used on Lexmark lx2480
Hi, This device is seems to be based on some custom soc (arm9 or mips probably). I have tried to make some sense out of the data and have found out that shortest repeating pattern on completely white is 6 bits long. This pattern is 1010 00 or some other variation of same pattern of one's. I have also found out that when there's some other color on the input, this "exception" seems to start with 1010 01 or 1010 11. There's a good example on line 16 of 203.d For colored scans white is 1010 00. I'm guessing that one 6 bit white accounts for 64 pixels. xres * yres / number of 6 bit sequences on one usb bulk packet / number of bulk packets. 2400 * 3000 / 187.0 / 599.0 = ~64.27 . This would seem more than just a coincidence Unfortunately completely black scan don't seem possible due to noise. I even tried killing leds that light the paper... Anyway, do you have any idea what compression algorithm could this be? usbmon dumps and images are at http://www.rasterburn.org/~aet/lx2480/ . I have stripped out everything but incoming bulk messages from that dump. Thanks -- Aapo Tahkola
[sane-devel] compression used on Lexmark lx2480
On Thu, 25 Oct 2007 06:35:28 +0200 stef wrote: > Hello, > > there seems to be some acces rights problems. > I get: > "You don't have permission to access /~aet/lx2480/203.jpg on this > server." > > Regards, > Stef > Fixed. -- Aapo Tahkola
[sane-devel] anyone working on Lexmark X2330 support?
Hi. On Sat, 14 Jun 2008 19:37:10 +0800 Paul Wise wrote: > Hi all, > > [Please CC me in all replies] > > I've had a Lexmark X2330 sitting next to the family Windows box for a > couple of years, figured it was time to make it work in Linux. > > Is anyone else working on Lexmark X2330 support? > > The protocol seems fairly simple at first glance, so it shouldn't be > much work if no-one has attempted to get it working yet. > I tried to hack compression algo used on Lexmark lx2480 without success. I sort of gave up because it turned out being so difficult to get any sort of "controlled data" out of it. Every scan is different and lexmark drivers only saves in lossy image format, making comparison difficult. Tying some of the data pins high/low might help with this to some degree. It didn't appear to be adaptive IIRC. http://lists.alioth.debian.org/pipermail/sane-devel/2007-October/020075.html has some speculation and some data if you want to compare. -- Aapo Tahkola