Updated "added support for partial bitstream decoding"

[Neopallium]

This is an updated version of #1251 by @chafey

[rouault]

• indentations issues to fix: https://github.com/uclouvain/openjpeg/runs/4991439810?check_suite_focus=true
• it breaks the test suite, on I suppose images that were corrupted, so I assume that strict mode isn't correctly initialized
• can you point to examples of images that in non-strict mode decode with this functionality ?

[Neopallium]

• Thanks. I couldn't see the code-style issues in the old PR. Will fix.
• Strict mode should be the default. I will check.
• I can't share the images that I am using for testing. I will see if I can find one from the test-suite or make one.

[Neopallium]

@rouault A good file for testing partial codestream decoding is input/nonregression/test_lossless.j2k

I did tests with truncated versions of that file at 32k, 64k, and 128k sizes. The opj_decompress command can produce an image when using the -allow-partial flag.

dd if=$OPJ_DATA_ROOT/input/nonregression/test_lossless.j2k of=./test_lossless_32k.j2k bs=32768 count=1
dd if=$OPJ_DATA_ROOT/input/nonregression/test_lossless.j2k of=./test_lossless_64k.j2k bs=65536 count=1
dd if=$OPJ_DATA_ROOT/input/nonregression/test_lossless.j2k of=./test_lossless_128k.j2k bs=131072 count=1
opj_decompress -allow-partial -i ./test_lossless_32k.j2k -o ./test_lossless_32k.png
opj_decompress -allow-partial -i ./test_lossless_64k.j2k -o ./test_lossless_64k.png
opj_decompress -allow-partial -i ./test_lossless_128k.j2k -o ./test_lossless_128k.png

[ouyangmingjun-work]

   I want to ask a question of great application value. In our actual use, there is often intermediate packet loss for packet transmission. At this time, we find that once packet loss begins, the subsequent superimposed packets will affect the quality of the whole graph. I want to ask why this phenomenon exists. Is intermediate packet loss not allowed? It is very important for progressive transmission. The middle part of the packet will be lost when it is used
    For example, I get j2k after image compression. I divide it into ten packages. The first package is added and combined, and the image is decompressed. The image is a gradual process of clarity. But once a package is lost in the middle (assuming the fifth package), the next package is superimposed (the sixth package), the image clarity of the decompressed image is worse, which does not conform to the theory that the more information, the clearer the image.

[Neopallium]

@ouyangmingjun-work
Support for "jpeg2k progressive transmission" requires that packets are only append in correct order. If one packet is lost (packet 5), the the packets 6-10 can't be appended until packet 5 has be re-transmitted. This should only be possible when using a protocol (UDP) that doesn't do retransmission or reordering of packets.

[ouyangmingjun-work]

Thank you very much for your answer. What I want to ask is, can other open source software achieve the effect I want? It is to allow packets to be lost in the middle

[Neopallium]

No. All Jpeg2K decoding libraries would have the same issue. By "packets" I mean network packets.

You can try filling the missing packet 5 with zeros in the decode buffer before appending the next packet 6. This requires that your "packet" protocol tracks the byte offset of each packet (or if all packets are the same length). The decoding logic might still have a problem with skipping over the zeros if it was expecting some important header. So the decode buffer would be filled like (packets 1-4, zeros to replace packet 5, packets 6-10). Based on your description it seems that your decode buffer is filled with (packets 1-4, packets 6-10), which would cause problems with trying to decode the data after packet 4, since the data for packets 6-10 would be at the wrong offset and look like corrupted data. If the missing packet is received later (can happen with UDP based protocols) after packet 6, then it can replace the zeros in the decode buffer.

Jpeg2k's progressive transmission (and I think normal Jpeg?) feature is not for missing packets. It is for allowing decoding when only X% of the data has been received (that X% is without gaps or missing packets). HTTP range requests can allow a client to request just the first 1k of all images on a page (where the images could be very large) and then should at least a low quality version of the image, before continuing to downloading more of each image as needed.

SecondLife does that for the texture of 3d objects, since the 3d viewer needs to download all the textures when moving to a new location. There can be 100-1000 textures that need to be downloaded and displayed quickly. So the viewer only downloads the first 1k of each image, so it can start showing something, then it progressively downloads more of each image for objects that are visible to improve the quality.

[ouyangmingjun-work]

Thank you very much for your patience and detailed answer.