On Tue, Nov 29, 2011 at 10:44 AM, Florent Thiery <[email protected]>wrote:
> Hello > > - is a (jpeg) compression applied to the images when grabbing a JP4 > stream ? In other words, is the compression rate parameter having an effect > in JP4 mode ? > > Florent, yes, JPEG compression is applied and the quality parameters is applicable. This quality is calculated according to JPEG suggested formulas. It is more tricky but still possible to use arbitrary quantization tables. When you specify quality 100% there is no quantization, but the files will be large. > - (how) can i render a JP4 image to RGB using ImageJ plugins ? I can > successfully import it (but it is still gray with squares) > > In ImageJ you are getting just raw Bayer mosaic data - same as the sensor outputs. That is the whole goal of the JP4 format - preserve as much as possible of the actual senor data while providing reasonable compression(determined by your bandwidth budget). Normal JPEG is designed primarily for image distribution, JP4 modification is camera-centric, providing a way to get data from the sensor to the post-processing computer. Converting from Bayer mosaic is not a trivial task, there is no single "best" conversion - there are many different de-mosaic or de-bayer algorithms, each with different features. Some may work better for nature photos, some - for photos with multiple straight and parallel lines (such as text, or photos of man-made structures, like buildings or fences). I was able to find some ImageJ de-bayer algorithms, but they were rather basic. When processing Eyesis images each color component is first processed for aberration correction separately as there is always some of chromatic aberration in the images. At the next stage the colors are combine with the frequency-domain algorithm we called "spectral scissors" - aliases are removed according to the nature of the image, and the shape of the separating "cuts" for red and blue components (they have less resolution than green and so closer/more overlapping aliases) are calculated using the information from the green channel. This implementation is designed to work on subdivided pixel grid - during the aberration correction we convert each color component to 20MPix images (2x in each direction) and then reduce resolution to the original only on the very last stage of the processing. You may find illustration of this de-mosaic process in the blog post - http://blog.elphel.com/2010/11/zoom-in-now-enhance/ (around last 1/3 of it) , the image itself is here - http://blogs.elphel.com/wp-content/uploads/2010/11/scissors.png It is possible to run this algorithm on JP4 images without aberration correction with http://elphel.git.sourceforge.net/git/gitweb.cgi?p=elphel/ImageJ-Elphel;a=blob(correction requires kernels that are calculated with Aberration_Calibration.java > > - is there a C implementation somewhere similar to our JP46 to bayer > > code<http://code.google.com/p/gst-plugins-elphel/source/browse/trunk/jp462bayer/src/gstjp462bayer.c#856> > so > that we can port it ? If not, where can we have more information regarding > the difference between JP46 and JP4, and the according decoding adjustments > needed ? > > Yes, there is a C implementation of the JP4 conversion, but I would recommend you to keep an eye on the java implementation in ImageJ plugin. Once in a while we add more parameters that are passed from the camera via Exif MakerNote field, and the ImageJ implementation is always maintained to match the latest camera firmware. And it still is compatible with the older firmware releases - so far we were appending new data to the end of the MakerNote, so the beginning of it stays the same. You may find C-code here: http://wiki.elphel.com/index.php?title=Movie2dng(or just search for movie2dng ) , but it may be a little behind the latest MakerNote. Andrey > > > >
_______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
