- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi There!
I am working with a C++ Image Server where I need to convert Aperio (TIFF) imagesto JPEGs and send to Front end (which is a .NET application). At the minute we support jpeg compressed tiffs. These are quite easy to work with since the tiff library can pull out and decode the tiles from a tiff directly. The new requirement is to support jpeg2000 compressed tiffs. So I thought to extract JPEG2000 encoded tile using TIFF Lib and use INTEL Performance primitives library V6.x to decode it.
AccordinglyI amtrying to decode the TIFF Image (got sample code from UIC Sample downloaded from Intel site)and then encoding the output data as a JPEG as my final objective is to get a JPEG as the outcome from Imageserver. But always I see a blank image as an output. I know JPEG Encoding work OK as it gives me the expected results for other images. So the problem should be with JPEG2000 Decoding.
Can any one please tell me if this is possible to decode a JPEG2000 compressed TIFF image using Intel libs? I can post the code snippet if you want to look at it. Thanks much in advance.
Please respond to my problem.
Regards,
Vishala
I am working with a C++ Image Server where I need to convert Aperio (TIFF) imagesto JPEGs and send to Front end (which is a .NET application). At the minute we support jpeg compressed tiffs. These are quite easy to work with since the tiff library can pull out and decode the tiles from a tiff directly. The new requirement is to support jpeg2000 compressed tiffs. So I thought to extract JPEG2000 encoded tile using TIFF Lib and use INTEL Performance primitives library V6.x to decode it.
AccordinglyI amtrying to decode the TIFF Image (got sample code from UIC Sample downloaded from Intel site)and then encoding the output data as a JPEG as my final objective is to get a JPEG as the outcome from Imageserver. But always I see a blank image as an output. I know JPEG Encoding work OK as it gives me the expected results for other images. So the problem should be with JPEG2000 Decoding.
Can any one please tell me if this is possible to decode a JPEG2000 compressed TIFF image using Intel libs? I can post the code snippet if you want to look at it. Thanks much in advance.
Please respond to my problem.
Regards,
Vishala
Link Copied
21 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vishala,
As a part of UIC sample we provide two applications, command line uic_transcoder_con and GUI picnic. Both can be used to see how to decode JPEG2000 files with UIC codec. Did you have a chance to try those?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Hi Vishala,
As a part of UIC sample we provide two applications, command line uic_transcoder_con and GUI picnic. Both can be used to see how to decode JPEG2000 files with UIC codec. Did you have a chance to try those?
Regards,
Vladimir
here is the error-
Unhandled exception at 0x773859c3 in uic_encode_test.exe: 0xC0000005: Access violation reading location 0x0aaf60f3.
And the call stack is -
> uic_encode_test.exe!UIC::Image::~Image() Line 561 + 0xf bytes C++
uic_encode_test.exe!ReadImageJPEG2000(UIC::BaseStreamInput & in={...}, _PARAMS_JPEG2K & param={...}, CIppImage & image={...}) Line 419 + 0x73 bytes C++
uic_encode_test.exe!DecodeImage(UIC::BaseStreamInput & in={...}, CIppImage & image={...}, CMD_OPTIONS & cmdOpt={...}, _MT_TYPE & fmt=MT_JPEG2000, double * msec=0x0017fa20) Line 165 + 0x14 bytes C++
uic_encode_test.exe!main(int argc=1, char * * argv=0x011b4f58) Line 535 + 0x22 bytes C++
uic_encode_test.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C
uic_encode_test.exe!mainCRTStartup() Line 399 C
Thanks,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think if you can attach one extracted tile from your TIFF file that could help us to investigate the problem. I would suspect that image header information in single tile may contain the whole image size where as actual data only for single tile or something like this.
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
I think if you can attach one extracted tile from your TIFF file that could help us to investigate the problem. I would suspect that image header information in single tile may contain the whole image size where as actual data only for single tile or something like this.
Vladimir
Hi Vladimir,
I have the attached the TIFF file to this post. I saved the image buffer in a file "jpeg2k.jp2" and attached here. Hope that it will give some pointers to investigate the problem.
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
I think if you can attach one extracted tile from your TIFF file that could help us to investigate the problem. I would suspect that image header information in single tile may contain the whole image size where as actual data only for single tile or something like this.
Vladimir
Hi Vladimir,
I have the attached the TIFF file to this post. I saved the image buffer in a file "jpeg2k.jp2" and attached here. Hope that it will give some pointers to investigate the problem.
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, I looked briefly over the image. It can't be decoded even third-party JPEG2000 decoder. I think the problem is that some critical information probably missed from it. Usually, tiled formats store some common image information, like tables, separately. So the application should combine all necessary info before feed to decoder (compressed data plus image header, tables and so on).
Regards,
Vladimir
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Thanks, I looked briefly over the image. It can't be decoded even third-party JPEG2000 decoder. I think the problem is that some critical information probably missed from it. Usually, tiled formats store some common image information, like tables, separately. So the application should combine all necessary info before feed to decoder (compressed data plus image header, tables and so on).
Regards,
Vladimir
Regards,
Vladimir
Thank you very much for the information. Is it possible for you to find out what information is missing exactly? Or else please let me know how can I find out because I am very new to this kind of work. Thanks again.
ishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, we will look into it more deeply a bit later. You also can refer to specification of TIFF format where it should be described how image is splitted into tiles.
Vladimir
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Yes, we will look into it more deeply a bit later. You also can refer to specification of TIFF format where it should be described how image is splitted into tiles.
Vladimir
Vladimir
Thanks,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our expert will look at this next week. I did not find any related info either. You might be interested to review Aperio documentbut unfortunately it does not contain all technical details about their file format.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Our expert will look at this next week. I did not find any related info either. You might be interested to review Aperio documentbut unfortunately it does not contain all technical details about their file format.
Regards,
Vladimir
ok Thank you. yeah I had also read the document a while back to brush up my knowledge on Image compression. Will be looking forward for your help.
Thank you,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do not expect much from us. We can detect what information missed in stream you provided but we can't suggest you where to extract this info from as it seems SVS is proprietory file format.
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Do not expect much from us. We can detect what information missed in stream you provided but we can't suggest you where to extract this info from as it seems SVS is proprietory file format.
Vladimir
Yeah that information would be fine and just I came to know that the individual tiles of a JPEG2000-compressed SVS file are stand-alone JPEG2000 images and no additional header information is required to decode it. And also the tiles are encoded with YUYV color representation (also sometimes called YUV-16). But I dont see such color representation in jpegbase.h (a class where the colors are defined). Do you have any idea what is the equivalent color representation here? Currently I am setting this JC_RGB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To identify YUYV format in UIC we do use two parameters, JC_YCbCr - to specify YUV colorand JS_422 - to specify 4:2:2 subsampling
Regards,
Vladimir
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
first SOT marker body looks problemmatic, because of non-standard length ("0D")
FF 90 00 0D 0A 00 00 00 00 06 4A 00 01
but even fixing it to
FF 90 00 0A 00 00 00 00 06 4A 00 01
(064a close to the length, but not exact, that is bad and looks like got from other tile-part)
or to more generic
FF 90 00 0A 00 00 00 00 00 00 00 01
(zero length is quite acceptable for single tile-part at the end of stream).
doesn't solve the problem (for third-party codec as well).
Because both markers and data looks realistic, at least after fixing SOT, (data looks good FF D9 (SOD) - FF 93 (EOC) are in place in the stream) it looks like some mismatch in coding options, which is specified in markers evenbefore FF 93 (SOT) and codestream data itself. Both our and reference decoder detects (before fail) wrong bit-padding in packet headers, that usually happen when data is corrupted.
It might be mismatched SIZ CODQCD or QCC marker, (if tile size is 240x240, 8-bit depth, sampling 2:1:1 factors, SIZ looks Ok).
It might be absent first tile-part header makrers, which actually can change options specified for entire tile or mainheader.
But all of these areonly assumptions.
You might try reference codec (Jasper)on the stream to check that everything Ok first. If it's fail both with IPP the problem is likelyin the stream, not in the codec.
If you have tile separating routines, you can look into it and check my assumptions.
Best Regards,
Mikhail
first SOT marker body looks problemmatic, because of non-standard length ("0D")
FF 90 00 0D 0A 00 00 00 00 06 4A 00 01
but even fixing it to
FF 90 00 0A 00 00 00 00 06 4A 00 01
(064a close to the length, but not exact, that is bad and looks like got from other tile-part)
or to more generic
FF 90 00 0A 00 00 00 00 00 00 00 01
(zero length is quite acceptable for single tile-part at the end of stream).
doesn't solve the problem (for third-party codec as well).
Because both markers and data looks realistic, at least after fixing SOT, (data looks good FF D9 (SOD) - FF 93 (EOC) are in place in the stream) it looks like some mismatch in coding options, which is specified in markers evenbefore FF 93 (SOT) and codestream data itself. Both our and reference decoder detects (before fail) wrong bit-padding in packet headers, that usually happen when data is corrupted.
It might be mismatched SIZ CODQCD or QCC marker, (if tile size is 240x240, 8-bit depth, sampling 2:1:1 factors, SIZ looks Ok).
It might be absent first tile-part header makrers, which actually can change options specified for entire tile or mainheader.
But all of these areonly assumptions.
You might try reference codec (Jasper)on the stream to check that everything Ok first. If it's fail both with IPP the problem is likelyin the stream, not in the codec.
If you have tile separating routines, you can look into it and check my assumptions.
Best Regards,
Mikhail
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi - I'm Ole Eichhorn, CTO of Aperio.
We have a library which encapsulated TIFF files with tiles compressed with JPEG2000 compression. Please contact me at ole@aperio.com for more information.
Quoting - vishalamcagmail.com
We have a library which encapsulated TIFF files with tiles compressed with JPEG2000 compression. Please contact me at ole@aperio.com for more information.
Quoting - vishalamcagmail.com
Hi There!
I am working with a C++ Image Server where I need to convert Aperio (TIFF) imagesto JPEGs and send to Front end (which is a .NET application). At the minute we support jpeg compressed tiffs. These are quite easy to work with since the tiff library can pull out and decode the tiles from a tiff directly. The new requirement is to support jpeg2000 compressed tiffs. So I thought to extract JPEG2000 encoded tile using TIFF Lib and use INTEL Performance primitives library V6.x to decode it.
AccordinglyI amtrying to decode the TIFF Image (got sample code from UIC Sample downloaded from Intel site)and then encoding the output data as a JPEG as my final objective is to get a JPEG as the outcome from Imageserver. But always I see a blank image as an output. I know JPEG Encoding work OK as it gives me the expected results for other images. So the problem should be with JPEG2000 Decoding.
Can any one please tell me if this is possible to decode a JPEG2000 compressed TIFF image using Intel libs? I can post the code snippet if you want to look at it. Thanks much in advance.
Please respond to my problem.
Regards,
Vishala
I am working with a C++ Image Server where I need to convert Aperio (TIFF) imagesto JPEGs and send to Front end (which is a .NET application). At the minute we support jpeg compressed tiffs. These are quite easy to work with since the tiff library can pull out and decode the tiles from a tiff directly. The new requirement is to support jpeg2000 compressed tiffs. So I thought to extract JPEG2000 encoded tile using TIFF Lib and use INTEL Performance primitives library V6.x to decode it.
AccordinglyI amtrying to decode the TIFF Image (got sample code from UIC Sample downloaded from Intel site)and then encoding the output data as a JPEG as my final objective is to get a JPEG as the outcome from Imageserver. But always I see a blank image as an output. I know JPEG Encoding work OK as it gives me the expected results for other images. So the problem should be with JPEG2000 Decoding.
Can any one please tell me if this is possible to decode a JPEG2000 compressed TIFF image using Intel libs? I can post the code snippet if you want to look at it. Thanks much in advance.
Please respond to my problem.
Regards,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ole,
glad to see you on Intel IPP forum.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - mkulikov
Hi,
first SOT marker body looks problemmatic, because of non-standard length ("0D")
FF 90 00 0D 0A 00 00 00 00 06 4A 00 01
but even fixing it to
FF 90 00 0A 00 00 00 00 06 4A 00 01
(064a close to the length, but not exact, that is bad and looks like got from other tile-part)
or to more generic
FF 90 00 0A 00 00 00 00 00 00 00 01
(zero length is quite acceptable for single tile-part at the end of stream).
doesn't solve the problem (for third-party codec as well).
Because both markers and data looks realistic, at least after fixing SOT, (data looks good FF D9 (SOD) - FF 93 (EOC) are in place in the stream) it looks like some mismatch in coding options, which is specified in markers evenbefore FF 93 (SOT) and codestream data itself. Both our and reference decoder detects (before fail) wrong bit-padding in packet headers, that usually happen when data is corrupted.
It might be mismatched SIZ CODQCD or QCC marker, (if tile size is 240x240, 8-bit depth, sampling 2:1:1 factors, SIZ looks Ok).
It might be absent first tile-part header makrers, which actually can change options specified for entire tile or mainheader.
But all of these areonly assumptions.
You might try reference codec (Jasper)on the stream to check that everything Ok first. If it's fail both with IPP the problem is likelyin the stream, not in the codec.
If you have tile separating routines, you can look into it and check my assumptions.
Best Regards,
Mikhail
first SOT marker body looks problemmatic, because of non-standard length ("0D")
FF 90 00 0D 0A 00 00 00 00 06 4A 00 01
but even fixing it to
FF 90 00 0A 00 00 00 00 06 4A 00 01
(064a close to the length, but not exact, that is bad and looks like got from other tile-part)
or to more generic
FF 90 00 0A 00 00 00 00 00 00 00 01
(zero length is quite acceptable for single tile-part at the end of stream).
doesn't solve the problem (for third-party codec as well).
Because both markers and data looks realistic, at least after fixing SOT, (data looks good FF D9 (SOD) - FF 93 (EOC) are in place in the stream) it looks like some mismatch in coding options, which is specified in markers evenbefore FF 93 (SOT) and codestream data itself. Both our and reference decoder detects (before fail) wrong bit-padding in packet headers, that usually happen when data is corrupted.
It might be mismatched SIZ CODQCD or QCC marker, (if tile size is 240x240, 8-bit depth, sampling 2:1:1 factors, SIZ looks Ok).
It might be absent first tile-part header makrers, which actually can change options specified for entire tile or mainheader.
But all of these areonly assumptions.
You might try reference codec (Jasper)on the stream to check that everything Ok first. If it's fail both with IPP the problem is likelyin the stream, not in the codec.
If you have tile separating routines, you can look into it and check my assumptions.
Best Regards,
Mikhail
Thank you. I will check these points.
Regards,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - ole-eichhorn
Thank you Ole. Happy to see your response. I will contact you.
Regards,
Vishala
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - ole-eichhorn
Thank you Ole. Happy to see your response. I will contact you.
Regards,
Vishala
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