- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello there,
On my dual core Macbook Pro I get the right part of any JPEG encoded image in a strange color if I use JS_422 or JS_244. 411 and 444 are fine. 444 works both cores but 411 does not. 444 is too slow and 411 is slow due to the singe core usage.
I'm just wondering if anyone knows what's going on?
The attached image shows it kind of good, but it's really exactly always on the right half (the screenshot is from the app and it paints multiple images on top).
I must admit that I don't fully understand the implications of the different JS_modes.. Especially since you can set it both on the source and destination in the encoder, AND the decoder..
I'm using UIC on IPP v6.1u1 on a Mac and here's the source code:
void init()
{
ippStaticInit();
}
int encode(Ipp8u *source, Ipp32s pixelsRowStep, Ipp32s width, Ipp32s height, Ipp32s qual, Ipp8u *dest, int destLen)
{
CJPEGEncoder *encoder = new CJPEGEncoder();
IppiSize size = {width, height};
int sourceLen = pixelsRowStep * size.height * 4;
CMemBuffOutput *compBufOut = new CMemBuffOutput();
compBufOut->Open(dest, destLen);
JERRCODE jerr = encoder->SetSource(source, pixelsRowStep * 4, size, 4, JC_RGBA, JS_411, 8);
if (jerr == JPEG_OK)
jerr = encoder->SetDestination(compBufOut);
if (jerr == JPEG_OK) // JS_411 or 444 here works nicely
jerr = encoder->SetParams(JPEG_BASELINE, JC_YCBCR, JS_422, 0, 0, qual);
if (jerr == JPEG_OK)
jerr = encoder->WriteHeader();
if (jerr == JPEG_OK)
jerr = encoder->WriteData();
unsigned long long len;
if (jerr == JPEG_OK)
compBufOut->Position(len);
delete encoder;
delete compBufOut;
return (int) (jerr != JPEG_OK ? jerr : len);
}
int decode(Ipp8u *source, Ipp32s sourceLen, Ipp8u *dest)
{
CJPEGDecoder *decoder = new CJPEGDecoder();
CMemBuffInput *sourceInput = new CMemBuffInput();
sourceInput->Open(source, sourceLen);
decoder->SetSource(sourceInput);
int width, height, comps, pres;
JCOLOR col;
JSS jss;
JERRCODE jerr = decoder->ReadHeader(&width, &height, &comps, &col, &jss, &pres);
IppiSize size = {width, height};
if (jerr == JPEG_OK) {
dest[0] = 255;
jerr = decoder->SetDestination(dest, size.width * 4, size, 4, JC_RGBA, jss, pres);
}
if (jerr == JPEG_OK)
jerr = decoder->ReadData();
delete decoder;
delete sourceInput;
return (int) (jerr != JPEG_OK ? jerr : (size.width * size.height * 4));
}
Cheers,
Mikael Grev
On my dual core Macbook Pro I get the right part of any JPEG encoded image in a strange color if I use JS_422 or JS_244. 411 and 444 are fine. 444 works both cores but 411 does not. 444 is too slow and 411 is slow due to the singe core usage.
I'm just wondering if anyone knows what's going on?
The attached image shows it kind of good, but it's really exactly always on the right half (the screenshot is from the app and it paints multiple images on top).
I must admit that I don't fully understand the implications of the different JS_modes.. Especially since you can set it both on the source and destination in the encoder, AND the decoder..
I'm using UIC on IPP v6.1u1 on a Mac and here's the source code:
void init()
{
ippStaticInit();
}
int encode(Ipp8u *source, Ipp32s pixelsRowStep, Ipp32s width, Ipp32s height, Ipp32s qual, Ipp8u *dest, int destLen)
{
CJPEGEncoder *encoder = new CJPEGEncoder();
IppiSize size = {width, height};
int sourceLen = pixelsRowStep * size.height * 4;
CMemBuffOutput *compBufOut = new CMemBuffOutput();
compBufOut->Open(dest, destLen);
JERRCODE jerr = encoder->SetSource(source, pixelsRowStep * 4, size, 4, JC_RGBA, JS_411, 8);
if (jerr == JPEG_OK)
jerr = encoder->SetDestination(compBufOut);
if (jerr == JPEG_OK) // JS_411 or 444 here works nicely
jerr = encoder->SetParams(JPEG_BASELINE, JC_YCBCR, JS_422, 0, 0, qual);
if (jerr == JPEG_OK)
jerr = encoder->WriteHeader();
if (jerr == JPEG_OK)
jerr = encoder->WriteData();
unsigned long long len;
if (jerr == JPEG_OK)
compBufOut->Position(len);
delete encoder;
delete compBufOut;
return (int) (jerr != JPEG_OK ? jerr : len);
}
int decode(Ipp8u *source, Ipp32s sourceLen, Ipp8u *dest)
{
CJPEGDecoder *decoder = new CJPEGDecoder();
CMemBuffInput *sourceInput = new CMemBuffInput();
sourceInput->Open(source, sourceLen);
decoder->SetSource(sourceInput);
int width, height, comps, pres;
JCOLOR col;
JSS jss;
JERRCODE jerr = decoder->ReadHeader(&width, &height, &comps, &col, &jss, &pres);
IppiSize size = {width, height};
if (jerr == JPEG_OK) {
dest[0] = 255;
jerr = decoder->SetDestination(dest, size.width * 4, size, 4, JC_RGBA, jss, pres);
}
if (jerr == JPEG_OK)
jerr = decoder->ReadData();
delete decoder;
delete sourceInput;
return (int) (jerr != JPEG_OK ? jerr : (size.width * size.height * 4));
}
Cheers,
Mikael Grev
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mikael,
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mikael,
in your decode sample it is not clear what you assign to jss parameter and how do you allocate memory for decoded image.
I would recommend you to take a look at UIC sample applications, picnic and uic_transcoder_con to see how do we intend to use UIC for decoding and encoding
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Valdimir,
The encode and decode is in a pair so what the encoder output the decoder gets which is why I find it hard that it's a bug in my app. That is why the decoder just use the js from the stream. It should be the same.
I have used UIC sample code as a template.
The buffers are alloced elsewhere, but they are static. There shouldn't be a problem there.
The strange thing is that JS_444, which is also multi threaded, works without a problem.
Cheers,
Mikael
The encode and decode is in a pair so what the encoder output the decoder gets which is why I find it hard that it's a bug in my app. That is why the decoder just use the js from the stream. It should be the same.
I have used UIC sample code as a template.
The buffers are alloced elsewhere, but they are static. There shouldn't be a problem there.
The strange thing is that JS_444, which is also multi threaded, works without a problem.
Cheers,
Mikael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mikael,
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Mikael,
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
things are not that simple to allow you just use parameters which describe compressed image (what you get from stream with ReadHeader call)in place of parameters to describe decoded image (what you have to set in SetDestination call).
The compressed JPEG images are usually subsampled to increase compression ratio whereas decompressed images usually are not subsampled. Have you ever seen somewhere RGB image with 422 sampling? Then why you are trying to get RGBA image with the same sampling which was used in JPEG for YCbCr color space (and most probably isone of subsampled formats)?
Regards,
Vladimir
Thanks Vladimir!
I thought the JS on the destintation was how to decode it. Setting it to 411 solves the problem.
Cheers,
Mikael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You probably mean JS_444 not JS_411?
Vladimir
Vladimir

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page