libheif icon indicating copy to clipboard operation
libheif copied to clipboard

JPEG 2000

Open dsookhoo opened this issue 2 years ago • 13 comments

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)

dsookhoo avatar Sep 12 '22 15:09 dsookhoo

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?

farindk avatar Sep 12 '22 16:09 farindk

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.

dsookhoo avatar Sep 12 '22 19:09 dsookhoo

Sounds interesting. Could you contact me at [email protected] to discuss your specific requirements and how we could approach this?

farindk avatar Sep 12 '22 21:09 farindk

Yes, of course.

dsookhoo avatar Sep 12 '22 22:09 dsookhoo

Why not just use the openjpeg2 library (or jasper) to write jp2/j2k containers (those are ISO BMFF as well by definition)?

kmilos avatar Sep 13 '22 07:09 kmilos

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.

silverbacknet avatar Sep 13 '22 10:09 silverbacknet

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.

farindk avatar Sep 13 '22 10:09 farindk

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.

kmilos avatar Sep 13 '22 11:09 kmilos

I have proposed #874

Is there any test data? Can gpac make some?

bradh avatar May 26 '23 11:05 bradh

@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.

dukesook avatar May 26 '23 14:05 dukesook

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.

farindk avatar Jun 10 '23 10:06 farindk

Yes, I will be available to work on PRs in about two weeks.

dukesook avatar Jun 12 '23 14:06 dukesook

I think that this is now fully implemented. Of course, there could be future enhancements under other tickets.

bradh avatar Dec 01 '23 22:12 bradh