<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I see a lot of sense in these assertions. However, what pops-up to me<br>
for a regular user is that it's an additional step they have to take,<br>
and most tools don't already feature this capability. It seems that, if<br>
we incorporate such a codec into the resulting product, then we will<br>
have to also have software ready for the consumer to use to do the<br>
post-processing.<br></blockquote><div><br>Yes, sure it needs software to process. But there are multiple ways how to make it seamless.<br><br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm looking at the page now. It's very interesting...<br>
</blockquote><div> </div><div>That page was designed to be a supplement to the article <a href="http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Elphel-camera-under-the-hood-from-Verilog-to-PHP/" target="_blank">http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Elphel-camera-under-the-hood-from-Verilog-to-PHP/</a> , but during some site re-design the articles got javascript corrupted<br>
<br></div><div>Here
is a link to ImageJ plugin for JP46. Additionally it reads Exif
MakerNote field and un-applies gamma and analog gains, so ImageJ gets
floating point pixel data proportional to the number of photons the
sensor actually detected:<br>
<a href="http://elphel.git.sourceforge.net/git/gitweb.cgi?p=elphel/ImageJ-Elphel;a=summary" target="_blank">http://elphel.git.sourceforge.net/git/gitweb.cgi?p=elphel/ImageJ-Elphel;a=summary</a><br></div><div class="im"><div>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> So far most JP46 images were used for still images (with Elphel model<br>
> 323 and 353 cameras) but now we at least some solutions for the video<br>
> and continue to work in this direction. And there could be<br>
> alternatives to literal JP4 implementation<br>
</div>I did see some video samples of the JP46 video, but I don't think I saw<br>
the resulting demosaiced video.<br>
</blockquote></div><div><br>There are several here and there - made by ourselves (i.e. <a href="http://community.elphel.com/videos/2010%2003.19-21%20CanyonLands/canyonlands_clip01.avi" target="_blank">http://community.elphel.com/videos/2010%2003.19-21%20CanyonLands/canyonlands_clip01.avi</a>), but you can find much more processed stills made by others.<br>
<br><br> </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It would be great if we had some raw Bayer video footage. I don't have<br>
any right now...can anyone point us to some? It would also be nice if<br>
JP46 was available as an actual codec to use for "compressing" the raw<br>
Bayer video as well. Supposedly my webcam (Logitech Webcam C600) has<br>
the ability to send raw Bayer pixel data, but I don't know in what<br>
format that is.<br></blockquote></div><div><br>Yes,
it could be applicable to other cameras too - JP4 is basically JPEG
with different color components and pixels rearranged for optimal
compression of Bayer data. Funny thing that I am not aware of any
software JP4/JP46 encoder - from the very beginning it ran in the
hardware (<a href="http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/fpga/x3x3/" target="_blank">http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/fpga/x3x3/</a>) - modified from the regular color 4:2:0 JPEG I implemented earlier. And there are multiple software decoders.<br>
<br>Andrey<br><br>PS. We do have cameras available for developers (<a href="http://wiki.elphel.com/index.php?title=Pricing/Discount/Donation_Policy">http://wiki.elphel.com/index.php?title=Pricing/Discount/Donation_Policy</a> )<br>
</div></div>