feat: Add heic/heif support

[SimonIT]

Description

This adds support for editing HEIC and HEIF images. Support for the decoding hook isn't merged yet (imazen/heic#5). There is also limited colour depth at this stage, as only RGB8/RGBA8 is currently supported. But it's a start!

Feel free to take a look at the decoding hook PR as well.

Closes #66

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

• Include heic

Screenshots/Videos

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: (e.g. Windows 11, macOS Sonoma, Ubuntu 24.04)
• Hardware: (e.g. Intel i7, Apple M2, Nvidia RTX 3060)

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[CyberTimon]

This is huge 😮. Last week I've checked and there was no pure rust heic / heif decoder. I wonder how this is possible, since there are many licensing issues regarding heic / heif. Can you verify if this is okay with their license of the heic / heif format in general?

I will take a look at this in the next days. Also the decoder has 0 GitHub stars and no reputation, might be good to verify first.

Thanks a lot! I will also take a look at this after my holidays.

Timon

[SimonIT]

Yes, it seems to be a brand new project — the first commit was on 22 January. Propably also the reason they have 0 stars. But they have managed to get it working:

I'm no legal expert. It's licensed under AGPL, so it should be fine.

[SimonIT]

https://github.com/nokiatech/heif/blob/master/LICENSE.TXT This seem to be the license for heif, but for HEIC I have no clue... But there seem to be other open source sdks, so there should be a way to use it

[CyberTimon]

@SimonIT Thanks for putting this together! It's super cool to finally see a pure Rust HEIC decoder, and I really appreciate you taking the time to integrate it.

I did some research into the licensing, and we have a pretty big blocker regarding software patents. While the imazen/heic code itself is open source (AGPL), the actual math and algorithms used to decode HEVC (H.265) images are protected by thousands of patents owned by companies like Nokia, Apple, and Samsung. The Nokia license you linked earlier only covers the HEIF container format, not the actual HEVC video codec inside it.

This is a notorious trap in open source. It's the reason why browsers like Firefox still refuse to ship HEVC decoders. If I compile this into the RapidRAW binaries for Windows, macOS, or Flatpak, I'm technically distributing an unlicensed HEVC decoder, which is a massive legal risk.

I'd love to get the crate author's take on this.

@lilith / @imazen Awesome work on the crate, a pure Rust HEVC decoder is a huge achievement. Since you offer it under AGPL and Commercial licenses, how do you handle the HEVC patent landscape (Access Advance, independent holders, etc.) for downstream projects? If a free open-source app like RapidRAW distributes compiled binaries that statically link your crate, does your license provide any patent coverage, or is the downstream distributor entirely responsible for navigating the patent pools?

@SimonIT What do you think about this? I'd love to hear your thoughts on the patent risk before we figure out the next steps for this PR.

Thanks!

[SimonIT]

Maybe this document gives some insights? https://www.diva-portal.org/smash/get/diva2:1721030/FULLTEXT02.pdf AI seem to suggest that a warning in the README might be enough that users might need a license. But as I said, I'm no expert

[CyberTimon]

@SimonIT

If you read the abstract of the exact paper you just linked, it proves the exact opposite of what your AI suggested, and confirms the massive legal blocker. It explicitly states:

"Our analysis of legal and licensing conditions for use of the standard shows significant obstacles. We find that it is impossible to obtain licences from patent holders that would allow for implementation and use of the standard in open source software."

In the eyes of patent law, putting a disclaimer or warning in the README does not protect the project. If we compile and distribute binaries (like Windows .exe files, macOS .dmgs, or Flatpaks) that contain an unlicensed HEVC decoder, we (the distributors) are committing patent infringement, regardless of what warnings we give to the end users. This is exactly why major open-source projects like Mozilla/Firefox refuse to ship HEVC decoders.

For now, we legally cannot merge and distribute this.

[SimonIT]

That's really disappointing. We could hide it behind a feature flag, meaning users would have to compile it themselves to support HEIC/HEIF files. This way, we technically wouldn't be distributing the codec via exe, etc.

[fstanis]

Hey @CyberTimon and @SimonIT, I looked into how some other apps do this, notably Chrome - it seems one patent-safe approach is to use a library to extract the HEVC stream from a HEIF file (which is not patent encumbered) and then delegate to either the OS (via Media Foundation, Video Toolbox or Media Codec) or hardware directly (via VA-API, CUDA or Vulkan) for decoding for the actual HEVC -> bitmap decoding.

Obviously, this won't work in all cases since it requires either the OS or the hardware manufacturer to hold a HEVC license (some some of them started disabling it due to mounting costs apparently), but it's better than no support I guess.

Regarding the actual effort, luckily, ffmpeg actually supports all of this as of version 8 (including even HEIF containers). I tried prototyping just the HEIF-via-ffmpeg part and came up with ffheif and then also tried to just plug it into RapidRAW in #1158 and it worked (at least on Linux and macOS; I haven't tested Windows)! I created a PR if you'd like to try it out, note though that I have very little Rust experience so most of the Rust code is AI-generated - would appreciate someone more experienced to review.