Basil,<br><br>Bayer components are better represented as different color
components (as they really are), they may have different analog gains
(so different noise), they are better compressed when DC levels are
calculated separately. And it is possible to have "hdr" mode by using
different gains for 2 greens (Gr, Gb) in the Gr, R/ B, Gb<br><font color="#888888">
<br>Andrey</font><br><br><div class="gmail_quote">On Wed, May 12, 2010 at 10:14 PM, Basil Mohamed Gohar <span dir="ltr"><<a href="mailto:abu_hurayrah@hidayahonline.org">abu_hurayrah@hidayahonline.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">On 05/12/2010 03:27 PM, Andrey Filippov wrote:<br>
><br>
> 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<br>
> 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>
><br>
><br>
> Yes, sure it needs software to process. But there are multiple ways<br>
> how to make it seamless.<br>
><br>
><br>
><br>
> I'm looking at the page now. It's very interesting...<br>
><br>
><br>
> That page was designed to be a supplement to the article<br>
> <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><br>
> , but during some site re-design the articles got javascript corrupted<br>
><br>
> Here is a link to ImageJ plugin for JP46. Additionally it reads Exif<br>
> MakerNote field and un-applies gamma and analog gains, so ImageJ gets<br>
> floating point pixel data proportional to the number of photons the<br>
> 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>
><br>
><br>
> > So far most JP46 images were used for still images (with Elphel<br>
> model<br>
> > 323 and 353 cameras) but now we at least some solutions for the<br>
> video<br>
> > and continue to work in this direction. And there could be<br>
> > alternatives to literal JP4 implementation<br>
> I did see some video samples of the JP46 video, but I don't think<br>
> I saw<br>
> the resulting demosaiced video.<br>
><br>
><br>
> There are several here and there - made by ourselves (i.e.<br>
> <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>),<br>
> but you can find much more processed stills made by others.<br>
><br>
><br>
><br>
><br>
> It would be great if we had some raw Bayer video footage. I don't<br>
> 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>
><br>
><br>
> Yes, it could be applicable to other cameras too - JP4 is basically<br>
> JPEG with different color components and pixels rearranged for optimal<br>
> compression of Bayer data. Funny thing that I am not aware of any<br>
> software JP4/JP46 encoder - from the very beginning it ran in the<br>
> hardware<br>
> (<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>)<br>
> - modified from the regular color 4:2:0 JPEG I implemented earlier.<br>
> And there are multiple software decoders.<br>
><br>
> Andrey<br>
><br>
> PS. We do have cameras available for developers<br>
> (<a href="http://wiki.elphel.com/index.php?title=Pricing/Discount/Donation_Policy" target="_blank">http://wiki.elphel.com/index.php?title=Pricing/Discount/Donation_Policy</a> )<br>
</div></div>I was thinking more about the JP4 codec, and I realized that all the<br>
data could be contained in a single luma channel for JPEG or Theora.<br>
Why, then, the need for the empty chroma channels in the case of JP4,<br>
because regular JPEG supports a grayscale mode that is just luma data.<br>
The same goes for Theora, and that is what I think we should jump<br>
straight into if we're going to use such an encoding scheme. Am I<br>
missing something? Is this basically what the MJP4 format is?<br>
<div><div></div><div class="h5">_______________________________________________<br>
theora mailing list<br>
<a href="mailto:theora@xiph.org">theora@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/theora" target="_blank">http://lists.xiph.org/mailman/listinfo/theora</a><br>
</div></div></blockquote></div><br>