- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Cindy,
you are right about JPEGView, it does not support this functionality yet (will be in future). But you can take a look on IJL-IPP sample, it supports YUV 422 sampled data as a input for encoder and as a output for decoder.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cindy
both IJL and JPEGView written in Intel, they are not belongs to IJG implementation. When IJL was separate library, in version 1.5 there was bug with multithreading, but it was fixed in the last IJL release as separate library (it was version 1.51). Since that there were no releases of IJL as separate library. Instead of that we reimplemented this library based on IPP and distribute it in source code form as IPP sample.
IJL can take YUV422 format, but can't work with YUV411 (or 420 as it called in MPEG4) directly. So you need to upsample chroma components to convert image into 422 format before pushing it to IJL
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,Vladimir,
Thanks.
Anyway, I don't want to do the upsampling, so I am now using IJG JPEG library. However, I encountered some problems when using jpeg_write_raw_data. Are you familar with it or has some examples using it? Thanks in advance.
BR//Cindy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Cindy,
Did you look at libjpeg.doc, which comes with IJG library? According to this:
Before calling jpeg_start_compress(), you must do
the following:
* Set cinfo->raw_data_in to TRUE. (It is set FALSE by jpeg_set_defaults().)
This notifies the library that you will be supplying raw data.
* Ensure jpeg_color_space is correct --- an explicit jpeg_set_colorspace()
call is a good idea. Note that since color conversion is bypassed,
in_color_space is ignored, except that jpeg_set_defaults() uses it to
choose the default jpeg_color_space setting.
* Ensure the sampling factors, cinfo->comp_info.h_samp_factor and
cinfo->comp_info.v_samp_factor, are correct. Since these indicate the
dimensions of the data you are supplying, it's wise to set them
explicitly, rather than assuming the library's defaults are what you want.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Cindy,
best wishes for you too.
I'll try to briefly describe architecture of JPEG codec in JPEGView sample in case you decide modify it for raw YUV data support. The main idea of this code was to provide mcu-row based processing, which minimizes amount of memory used in codec and so provides better cache usage. So, there is several buffers in each image color component, with width egual to mcu-row width and height equal to mcu height. If we are talking about encoder, the first buffer is so called "color conversion" bufer. It used as destination for IPP color conversion functions, with input from a source image. The second is "sampling buffer", it used to store down-sampled component's data. Later on this buffer used as a source for following FDCT, quantization and level-shift operations and finally huffman entropy encoding.
If you want to input raw, down-sampled data into encoder you need to consider a way to enter data directly into this "sampling buffer" bypassing color convertion step. If your data are in pixel-interleaved form you need first to separate them by planes, as we have separate "sampling buffer" for each JPEG color component.
Actually, we were planned to add raw YUV format support to encoder (as we did before for decoder), but we will start from 422 sampling as it widely used in MJPEG, so support for raw 411 sampled YUV datamightnot be available in the nearest release.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cindy,
according JPEG standard, before doing FDCT we need to do level-shift, you are right, it is change unsigned pixel representation to signed one. Practically, for 8-bit data it is add/sub constant 128. We have in IPP special functions to do that and we also have combined this operation with DCT and quantization for more effectiveness. You can look IPP manual for ippiDCTQntFwd8x8LS_JPEG_8u16s_C1 function for more details.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Vladimir,
1. Thanks. Is it because UV should be signed 8bit? Or all the 3 components (Y/U/V) should be converted into signed 8 bits for fast/ accurate computing?
2 Previously, I did a project using IPP sample Mpeg4Decoder to get the YUV file. Now, I am trying to connect the two.
Thus, I first convert the YUV2Jpeg.cpp into YUV2Jpeg.c. When I run under the "start without debugging" mode, it works, but the obtained jpeg image has a noise line at the top of the image. When I run under the "debug" mode, I must set the U/V components has the same heights as the Y component (In fact, the U/V has half heights as Y).
3. When I attach the jpegEncoder part to the Mpeg4Decoder, some even weird things happens. I often encounter some exception error. I suspect that I haven't done well with the memory. After mpeg4 decoder, there are some (at least 2) structures left in the memory, I don't know how to free them. Free the pointer member seems prohibited.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Vladimir,
I solve the problems 2 & 3. It's due to my miss sizeof in the malloc. :(
Thanks.
BR//Cindy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Cindy,
1) This required by JPEG standard
2&3) Please note, MPEG4 supports only YUV420 format, this is MPEG4 standard requirement, so you need to convert YUV422 you get from MJPEG to YUV420 format before applying it to MPEG4 encoder
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page