Re: MR97310A and other image formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
Yes, what you quote is the SOF marker for all of these cameras. The total header length, including the SOF marker ought to be 12 bytes. On all of the mr97310 cameras that I have dealt with, the last 5 bytes are obviously related somehow to the image (contrast, color balance, gamma, whatever). I have no idea how to interpret those values, but we can hope
that someone will figure out how.

Two of them are luminance values (middle and edge) for the PAC207.

Thus, it is not a good idea to throw them away as the driver is currently doing. If they have to be tossed, then toss them over in libv4lconvert, I would say, instead of shaving them off in the driver. It makes for much simpler driver code when one does not try to work around them, too.

Yes, there are always some additional Bytes in the SOF header for a good reason.

FF FF 00 FF 96 64 00     uncompressed
FF FF 00 FF 96 64 50 "standard compression" supported here and in libgphoto2/camlibs/mars. Supports all cameras in stillcam mode except for the next one listed FF FF 00 FF 96 64 20 another compression, used by one stillcam, not resolved FF FF 00 FF 96 64 D0 new compression algorithm used by all the 0x093a:0x010e cameras that I own (several of them), when running in streaming mode.

So, you found the meaning of an other Byte in the SOF header. I have to check whats in there for the PAC207 and PAC7311.

Incidentally, I did have something to do with solving the the 0x50 decompression. Bertrik Sikkens figured out the basics. It is a differential Huffman encoding, as I said. One computes a "predictor" for the next pixel to be decompressed by taking a weighted average of some previously decompressed pixel data. Then one applies a "corrector" which is the next piece of decoded data. Bertrik figured out the Huffman scheme, as I said. What I did was to figure out the right pixels to average for the predictor part and what weights they get assigned in the weighted average.

That is a similar compression like on the PAC207 the first 2 pixels of the line have the real value and for the other pixels, only the diff to these two pixels are stored in Huffman codes.
Now you can guess who found out how to decompress -> Bertrik Sikkens


But it seems that you know something about this kind of thing and probably have the right tools or clues to be able to handle them. I have a couple of other unsolved formats lying around, too. You might be the person I have been trying to meet. Interested?

Always interested, but my free time is very limited :-(

It looks like I have 22 webcams on my desk and 3 or 4 of them are _not_ working in Linux. Thus, I have a lot of homework to do.....

Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux