Re: [sqcam-devel] Advice wanted on producing an in kernel sq905 driver

[Hans de Goede <j.w.r.degoede@hhs.nl>]

kilgota@banach.math.auburn.edu wrote:
> 

<snip>

> 
>> Easiest way to get my latest code is here:
>> http://people.atrpms.net/~hdegoede/libv4l-0.5.5.tar.gz
>>
>> You are looking for libv4lconvert/bayer.c
> 
> Thanks. I got it. By your leave, the first thing I will do is to try to 
> speed up my own code. There are, I think, some real possibilities to do 
> that. However, without looking at any details of what you did in your 
> bayer.c, I will ask a question about organization of the way you did 
> things. What happens in libgphoto2 is, first a function is run which 
> "spreads out" the (uncompressed) raw data to a block of data of size 
> 3*w*h, so that each byte of actual data is in its natural place in the 
> finished image and the rest of the locations in the finished image are 
> left filled with 00 bytes. Then after this what the algorithm does is to 
> work on this copy of the still-not-finished image and to finish it, 
> entering each piece of computed or estimated data in its proper 
> location. There might be other ways to go about the entire project of 
> doing the Bayer demosaicing. Therefore, I ask whether you have done 
> things the same way, or did you take one of those other possible routes 
> to the final result? For example, in
> 
> static void bayer_to_rgbbgr24(const unsigned char *bayer,
>   unsigned char *bgr, int width, int height, unsigned int pixfmt,
>         int start_with_green, int blue_line)
> 
> (which looks like one of the relevant functions) is bgr of size w*h, 
> (size of uncompressed input) still, or of size 3*w*h (size of 
> interpolated RGB output)? I could figure out all of this stuff in 3 
> days, but probably not in 5 minutes.
> 

bayer is the raw bayer input here, and that is ofcourse w*h, bgr is w*3*h, and 
when this function is done contains complete rgb triplets for all pixels. This 
function does the "spread out" and the interpolating in one pass.

<snip>

>> p.s.
>>
>> If you are experienced with reverse engineering decompression 
>> algorithms 9for raw bayer), I've got multiple issues where you could 
>> help me.
>>
> 
> Haha. I was about to ask you the same. On my end, this is *the* problem. 

Hehe

<snip>

> As to the cameras I mentioned before, and who figured out the 
> decompression:
> 
> SQ905 and 905C     myself (took several years to get it all done right)
> 
> SN9C2028     macam project, with some improvements by myself after they 
> did the hard work. The code from the macam project was based, in turn, 
> on the work of Bertrik Sikkens on the SN9C10X cameras. The two 
> algorithms are similar but not identical.
> 

Interesting, so you are familiar with the sn9c10x bayer compression, as you 
then may remeber it uses differential compression with the following huffman codes:
0
100
101
1101
1111
11001
110000
1110xxxx /* direct set */

But sometimes it also sends:
110001xx

And we have no idea what this code means, does the sn9c2028 also have something 
similar and have you figured it out?

> MR97310 Bertrik figured out some of the basic stuff but it was never 
> right, until I was finally (after years) able to figure out what was 
> wrong. Again this is a differential Huffman encoding which is similar to 
> the one the Sonix cameras are using, but again different in details.
> 
> You want quick, go and ask Bertrik. He is, in my experience, either very 
> clever or very lucky.
> 

Ok, I'll ask him.

Thanks & Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list