- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The JPEG encoder provided in UIC samples supports only lossless encoding for single channel images when the destination color space is YCbCr.
While going through the code, I could not find the reason for it. More specifically, for lossless encoding of 8 bit images, these 3 steps are followed -
a) Color conversion of each row from source color-space to destination color space.
b) generation of predictors by computing difference between input sample and predictor.
c) finally, huffman encoding of predictors for each component.
All these 3 steps seem to be properly implemented for multi-channel images.
so, what could be the reason for non-support of multi-channel images?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only and single thing which is wrong in case of lossless compression of YCbCr data is JFIF file format. As I have said somehwere before, JFIF file format does not specify any indication of what color space was used at compression time. That mean the decoder have to know appriory what is color space (or have to assume some). The standard "de-facto" assumtion for JFIF format is that 3 channel image is compressed with using RGB-to-YCbCr conversion in case of lossy compression mode and without any color space conversion in case of lossless compression mode. When encoding application does not follow these assumtions then standard decoder (which do follow these assumtions) will not be able to correctly decode image. The UICJPEG decoderallow you tospecify actual color space if that can't be correctly determined from JFIF file format.
Regards,
Vladimir
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I'm not wrong, there is a difference between lossy and lossless JPEG regarding color space.
Lossy JPEG in RGB will transform the RGB into yCbCr, whereas Lossless JPEG in RGB will simply pack each RGB channel, with no transformation.
Putting it differently, for lossy jpeg, there is a color space parameter, but for lossles, there is none.
The reason would be, that for lossy JPEG, it is better to transform because you get better compression, but for lossless JPEG, it does not matter because compression would be the same.
I think you should set the destination color space to Unknown, when encoding lossless JPEG.
Alternatively, specify the same output color space as your source image has (RGB or BGR, I presume), although I do think there is a standard somewhere.
Also, think about this: a transformation from RGB to yCbCr would not be lossy, hence why do it with lossless JPEG?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Thomas, your comments absolutely correct.
And of course it is possible to compress YCbCr image using lossless compression mode with UIC JPEG codec (by specifiying appropriate parameters). The picnic application should demonstrate that ability through options menu. Although in that case decoder may have throubles to determine what color space was used at compression stage. As you probably know JPEG is color blind format, nothing in JFIF JPEG file says about color space used. So, there are some assumptions popular in the industry (but not quaranteed for every JPEG encoder)- 3 channel image encoded with lossy mode usually converted into YCbCr color space, 3 channel image encoded with lossless mode usually do not involve any color conversion step.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Thomas and Vladimir for your reply.
I agree that for lossless encoding, there should be no need to convert from RGB to YCbCr as we are not performing chroma subsampling in lossless mode.
My source of confusion is thesource file jpegenc.cpp (CJPEGEncoder class)
If you look at EncodeScanLossless function, you will find that there is a ColorConvert step which performs color space conversion.
Also, in picnic application (Check the attached pics), open a multi-channel bitmap and while saving it in JPG - LSL format, you will get two options - YCbCr & RGB. If you choose RGB, you will get the correct JPG file which can be decoded back to BMP and you get identical bit-pattern. But if you choose YCbCr and decode the resultant output back to BMP, you will not get an identical bit-pattern.
In this link, it is mentioned that Lossless mode supports one-channel images only (both JPEGView and picnic are using same source file jpegenc.cpp) ?
I restatemy doubts-
1. Should YCbCr option be disabled in LSL mode in picnic UI?
2. Going through EncodeScanLossless function in jpegenc.cpp, even if the color space conversion is taking from RGB to YCbCr, why the output image is distorted (i.e. color information of original image is lost and there's no way to get back to original image which is necessary for lossless encoding)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
To be honest I do not see enough reasons to remove possibility for someone use color conversion step, it just need to be understood that it will introduce some loss of information. By the way, JPEG lossless mode allow to use near-to-lossless mode, when you can specify point_transform parameter, which control how many less significant bits from image samples you allow to loose.
ColorConvertion function called from EncodeScanLossless function is responsible for color space conversion step or for copying data in internal buffers if no color space conversion required. You control wether you need color space conversion or not by specifying input image color space and resulting image color space in JPEG encoder parameters.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your reply, Vladimir.
Maybe I was not clear earlier. The thing is if you have a multi-channel source BMP and you try to save lossless jpeg with YCbCr color parameter, you get a totally different jpeg image (the color information is lost. Red color will become yellow etc..) I do not have picnic application right now but i will put a source and output image later. There's something wrong with lossless encoding when converting from rgb -> YCbCr. anyway, thanks. it may be possible that I am not properly doing it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only and single thing which is wrong in case of lossless compression of YCbCr data is JFIF file format. As I have said somehwere before, JFIF file format does not specify any indication of what color space was used at compression time. That mean the decoder have to know appriory what is color space (or have to assume some). The standard "de-facto" assumtion for JFIF format is that 3 channel image is compressed with using RGB-to-YCbCr conversion in case of lossy compression mode and without any color space conversion in case of lossless compression mode. When encoding application does not follow these assumtions then standard decoder (which do follow these assumtions) will not be able to correctly decode image. The UICJPEG decoderallow you tospecify actual color space if that can't be correctly determined from JFIF file format.
Regards,
Vladimir
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page