Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated "added support for partial bitstream decoding" #1407

Merged
merged 12 commits into from
Feb 10, 2022

Conversation

Neopallium
Copy link
Contributor

This is an updated version of #1251 by @chafey

@rouault
Copy link
Collaborator

rouault commented Jan 29, 2022

@Neopallium
Copy link
Contributor Author

  • 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
Copy link
Contributor Author

Neopallium commented Jan 29, 2022

@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

@rouault rouault merged commit 883c31d into uclouvain:master Feb 10, 2022
@Neopallium Neopallium deleted the partial_decode_mode branch April 30, 2022 12:31
@ouyangmingjun-work
Copy link

   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
Copy link
Contributor Author

@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
Copy link

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
Copy link
Contributor Author

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
Copy link

Thank you very much for your patience and detailed answer.

mtremer pushed a commit to ipfire/ipfire-2.x that referenced this pull request Jul 26, 2023
- Update from version 2.4.0 to 2.5.0
- Update of rootfile
- Changelog
    2.5.0 (May 2022)
	No API/ABI break compared to v2.4.0, but additional symbols for subset of
         components decoding (hence the MINOR version bump).
	* Encoder: add support for generation of TLM markers [\#1359]
          (uclouvain/openjpeg#1359)
	* Decoder: add support for high throughput \(HTJ2K\) decoding. [\#1381]
          (uclouvain/openjpeg#1381)
	* Decoder: add support for partial bitstream decoding [\#1407]
          (uclouvain/openjpeg#1407)
	* Bug fixes (including security fixes)

Signed-off-by: Adolf Belka <[email protected]>
Signed-off-by: Michael Tremer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants