I'm decoding a JPEG2000 stream from a source that seems to be using ADV202 to encode the data. The manufacturer simple says that the stream is 'JPEG2000 compatible', but the first bytes of every frame are the ones that define the ADV202 header, that is, FF FF FF F0 [Compressed image index], etc.
I found out that the code stream compressed image index (the 4 bytes that follow the field header FF FF FF F0) is repeated in 4 packets and then incremented, that is, the full image is divided in 4 'subimages'. Each part starts with the ADV202 field header and is followed by the JP2 id bytes (00 00 00 0C 6A 50 20 20 ) and the usual JP2/J2K markers, up to a EOC (FF D9) marker, with padding 00s later.
I'm trying to reconstruct the image by decoding the JPEG2000 in each one of the 4 packages and later combine the decoded images in a single one (the number of columns of each one of the 'subimages' is exactly 1/4 of the full image). This is not working, I'm able to decode each part but the image pattern is not what is expected - tried different decoders such as Irfanview, Kakadu and OpenJPEG2000 with the same results.
The attached image is one of these subimages decodeed, the reference is a black image, it is OK for 2/3 of the image but the rightmost 3rd is not black as expected:
Maybe the 4 packets must be combined somehow before decoding?
Most of the info that helped me to get this far is from this forum so thanks in advance.
The manufacturer of the equipment generating the stream said later they were using proprietary algorithm based on J2K (probably some tweak after ADV202 processing). The issue is closed then, the decompression…
Hi, I believe only its possible,A single ADV202 can be in either Encode or Decode mode depending on what firmware the user has loaded into the device. An ADV202 can not change from Encode mode to Decode mode unless new firmware is loaded into the chip and the chip has gone through a reset and configuration process again. Please refer ADV202 user guide http://www.analog.com/en/products/landing-pages/001/adv202-technical-documentation.html
Hi Poornima, thanks for your reply.
I don't think the problem is related to encode/decode mode changes. I'm receiving the stream from an equipment and developing a SW-based decoder for the stream.
My guess is that the equipment is using ADV202 for JPEG2000 encoding because I see the ADV202 header before each JP2 tile. More specifically the header for one tile is:
which indicates, accordingly to "ADV202 Output Formats and Attribute Data Format":
FFFFFFF0, even field delimiter
0000014B, compressed image index
02, J2C (bit 1 on), ADV202 header generated (bit 3 off), EPH/SOP/PLT not included (bits 4-6 off), PPT headers with
packet body (bit 7 off)
04, vformat, 1080i luminance
02, header version, encode firmwayre with app id = 0xFF82
0000007C, size of compressed data
after the header I have a JP2 signature and boxes:
00 00 00 00C 6A 50 20 20 0D 0A ....
it's strange that I found a JPEG2000 signature box even with the ADV202 header indicating J2C mode, I would expect the content to start with SOC (Start of Codestream) marker, FF 4F.
the figure below shows a hexdump of the tile:
There are some inconsistencies with the above JP2, specially in the color mapping, Kakadu's kdu_viewer for instance complains that:
“The component Mapping (cmap) and Channel Definition (cdef) boxes, or lack thereof, are insufficient to discover codestream components to associate with all color channels”
“JP2/JPX source is internally inconsistent. Either an explicit channel mapping box, or a set of channels implicitly identified by a color space box, cannot be associated with available codestream image components”.
The reason is that the defined color scheme is YCC but there is only one component.
I tried to extract only the codestream from the file and decode it, kdu_viewer warning messages were gone but he results was an image with the expected dimensions but with an artifact on the rightmost 3rd part, as shown in the first message.
Files for complete JP2 and J2K only may be downloaded from:
Hello. Any answer on this? Thank you in advance.
The manufacturer of the equipment generating the stream said later they were using proprietary algorithm based on J2K (probably some tweak after ADV202 processing). The issue is closed then, the decompression algorithm is also proprietary.