libheif
libheif copied to clipboard
JPEG 2000
Rather than encoding an image as an hcv1 image, I want to encode the image using JPEG 2000 and store it in a heif. Does libheif support this functionality?
The instructions for doing this are stored in the following document: https://www.iso.org/standard/80620.html (Unfortunately, the document isn't free)
In order to add this, one would have to write a codec plugin. These can be added to libheif dynamically, even from client code. See heif_register_encoder_plugin()
.
Since it is also a new compression format, I would have to add JPEG2000 to the list of compression formats and add the routing to the correct plugin.
What would be the use-case for this? Are there any applications using this and why?
Great, thanks for the help.
The use case is for cameras that collect J2k compressed in proprietary files. There is an incentive to replace these proprietary files with HEIF while preserving all J2K capabilities.
Sounds interesting. Could you contact me at [email protected] to discuss your specific requirements and how we could approach this?
Yes, of course.
Why not just use the openjpeg2 library (or jasper) to write jp2/j2k containers (those are ISO BMFF as well by definition)?
Why not just use the openjpeg2 library (or jasper) to write jp2/j2k containers (those are ISO BMFF as well by definition)?
Because that's not HEIF. The standard ISO approved and they want to switch to is just HEIF with a new codec, not just BMFF container with completely different format semantics. Pretty interesting, actually, now that jpeg2000 is completely out of patent and the newer but largely compatible HTJ2K is entirely royalty free.
Right, jp2 also has an ISO BMFF structure, but it is an ad-hoc specification only for JPEG 2000. Using the HEIF container has the advantage to also use the features from HEIF (tiled images, color profiles, alpha & aux channels, ...) together with JPEG 2000. Moreover, it may provide the link between legacy systems that still depend on JPEG 2000 and switching to a different codec in the future while keeping the overall file structure.
Ok, I get it is not as feature rich, but it is an ISO standard nonetheless. As a migration path, it does make sense indeed.
I have proposed #874
Is there any test data? Can gpac make some?
@bradh I created some test data here here: https://github.com/dukesook/enoji
The jpeg2k branch in libheif was used to create the test file. Currently, I have a working J2K in HEIF decoder on my fork of libheif that I'm cleaning up in preparation to be pushed back.
I've merged #874, which implements the J2k related boxes.
@dukesook Could you prepare some PRs to merge the encoder or decoder? I'd like to avoid that we have a huge PR at the end when both branches have diverged a lot. We can also do this in steps.
Yes, I will be available to work on PRs in about two weeks.
I think that this is now fully implemented. Of course, there could be future enhancements under other tickets.