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

Added support for high throughput (HTJ2K) decoding. #1381

Merged
merged 3 commits into from
Sep 25, 2021

Conversation

rouault
Copy link
Collaborator

@rouault rouault commented Sep 25, 2021

There are a few limitations:

  • mixed mode (HT and regular code blocks) is not supported
  • ROI in HT blocks is not supported
  • Placeholder passes are not supported.
  • MultiHT sets are not support, only a singleHT set.
  • there are known issues with some compliance testing files related to
    the parsing of packet header

Continuation of #1374, which is a work by @aous72

@rouault
Copy link
Collaborator Author

rouault commented Sep 25, 2021

@aous72 Does the PR text / commit message captures well the (known) limitations of the implementation ?

@aous72
Copy link
Contributor

aous72 commented Sep 25, 2021

@rouault
Thank you for your new edit.

Does the PR text / commit message captures well the (known) limitations of the implementation ?

All the points are correct. Perhaps, I would replace "only up to 3 coding passes are supported" with:

  • Placeholder passes are not supported.
  • MultiHT sets are not support, only a singleHT set.

The singleHT set can have up to 3 passes. Feel free to modify the text.

Thank you.

aous72 and others added 2 commits September 25, 2021 12:26
There are a few limitations:
- mixed mode (HT and regular code blocks) is not supported.
- ROI in HT blocks is not supported.
- Placeholder passes are not supported.
- MultiHT sets are not support, only a singleHT set.
- there are known issues with some compliance testing files related to
  the parsing of packet header.
@aous72
Copy link
Contributor

aous72 commented Sep 25, 2021

@rouault
The code works for little endian, and I put effort in making sure that reading is always aligned to the reading size. The code points you identify is definitely an issue for big endian. Do you have an idea how to test it big endian?

A second question: If I want to do more development, what should I do? clone it again?

@rouault
Copy link
Collaborator Author

rouault commented Sep 25, 2021

Do you have an idea how to test it big endian?

Travis-CI has a s390x big endian target but given their new economic model, it is impractical for open source projects if you don't subscribe to their service. Otherwise if you don't have access to a big endian box, you can potentially use qemu full system emulation with a big endian emulated machine (will be rather slow). Honestly, I wouldn't put too much effort on that given the very very low market share of big endian nowadays. Efforts on improving compliance and speed would be much better time investment.

A second question: If I want to do more development, what should I do? clone it again?

no, normally, you would just do

git checkout master
git pull origin
git checkout -b new_branch

but as your working branch was master (not recomended practice), you perhaps need to do something along

git checkout master
git fetch origin master
git reset --hard origin/master  # beware: will loose all your local changes !
git checkout -b new_branch

I'm assuming your origin remote points to uclouvain/openjpeg

@rouault rouault merged commit 1561575 into uclouvain:master Sep 25, 2021
@aous72
Copy link
Contributor

aous72 commented Sep 25, 2021

Thank you for your detailed explanation.

@malaterre
Copy link
Collaborator

@aous72

Do you have an idea how to test it big endian?

You can request access to a POWER machine here:

As mentionned by @rouault this should not be a top priority anyway.

@aous72
Copy link
Contributor

aous72 commented Dec 3, 2021

You can request access to a POWER machine here:
https://openpower.ic.unicamp.br/minicloud/

@malaterre Very useful suggestion. Thank you.

@rouault rouault mentioned this pull request Feb 13, 2022
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 <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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.

3 participants