Feature request: Support HEIC

[voltagex]

I am using 2.1.1 via Flatpak on Fedora 39. I'd like to be able to edit HEIC files.

[cameronwhite]

It looks like there is a GDK pixbuf loader for those formats (e.g. linuxmint/pix#134), so I think this should just work if that's installed (although we'd need to verify that)

If it does work, this would need to be added for:

• Windows installer
• macOS installer
• snap package
• flatpak package

[cameronwhite]

Testing on Ubuntu 23.10, installing heif-gdk-pixbuf allows a HEIC image to be loaded successfully in Pinta. But the pixbuf loader doesn't seem to have implemented support for saving, so any edits would need to be saved to another file format.

Testing on macOS, the libhheif package from Homebrew doesn't bundle the pixbuf loader currently

[JGCarroll]

For the snap, it'd be best to treat it the same as the webp pix-buf which was added to the Gnome extension so all other Gnome snaps could benefit from it too. Similarly I feel this is the kind of thing that would make sense in the Flatpak runtime rather than the Pinta Flatpak itself, but I'm less confident there if/how that would be done.

[cameronwhite]

Thanks! Yeah I agree it would be handy to have this in the runtime by default so that other apps can benefit easily

[JGCarroll]

For the snap side of this, I've seen this pop up in the news recently: https://www.omgubuntu.co.uk/2024/04/ubuntu-now-supports-heif-images

If HEIC support is in the default 24.04 install, it suggests that it's in the main repositories and could likely end up being trivial to get into Pinta's snap when it's repackaged for Core24 (which may be before of after 2.2 depending on timelines involved). Of course, this is really assuming it'll end up in the Gnome snap for Core24 since that's where it needs to be to work conveniently & for other apps to benefit.

[JGCarroll]

https://blogs.gnome.org/sophieh/2025/06/13/making-gnomes-gdkpixbuf-image-loading-safer

From what I'm reading here, so long as Pinta continues to follow upstream Gnome in future releases, HEIC and a load of other formats should become automatic across all platforms.

Trying to get HEIC into the Gnome platform snap is possible and has been in the back of my mind for a while; but given how close it seems to be that GDKPixBufs will become legacy, I'm not sure it's worth putting that extra burden on upstream when it sounds like this is now inevitable and the results will be better when it happens too. (Colour accuracy, HDR support, security, etc.)

[cameronwhite]

Very exciting! Yeah it sounds like it should "just work" as long as the glycin pixbuf loader is there (there might be some packaging work for Windows / macOS to make sure that happens). Or, in the future if gir.core gets bindings for the glycin library we could possibly use it directly without going through Gdk.Pixbuf

[JGCarroll]

I expect there'll be a lot of upstream snap work to get this to work too, I've not run any test builds but from what I'm interpreting from the blog, the sandboxing on Linux itself is mandatory, via Bubblewrap or Flatpak's own tools, and I doubt bubblewrap works with the permissions most desktop snaps would have.

So on the Linux releases, that means we could potentially see this later in the year (Flatpak seems guaranteed, assuming the SDK is updated), snap could be similar timing wise but could also be pushed back based on how that sandboxing caveat goes, because at a high level it likely involves:

• Changes to the desktop interface to accomodate new DBus calls
• Changes to snapd via the snapctl binary in the runtime environment to allow it to replace the functionality of flatpak-spawn
• Patches to Glycin to become aware of the snapctl changes so it can make use of them to create the subsandbox.

If the first bullet is required, this would also require a new minimum snapd version. Thankfully across most platforms, snapd either updates itself, or is updated in the distribution repos separately. But that might mean these changes get pushed back to Core26 depending on how the implementation ends up proceeding.

Thankfully none of that work will be us; but all this just means the encoding/decoding compatability might be a little more inconsistent until this is workable everywhere, but it sounds like there won't be any loss in support that's already there at least.

Hopefully the Windows/Mac scenario is just bundling the libraries into the installers.

[badcel]

It Looks like glycin is already Part of the GNOME Master SDK: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/elements/sdk-platform.bst#L23

It's Not present on the Gnome-48 branch though.

Docs: https://gnome.pages.gitlab.gnome.org/glycin/libglycin/

Perhaps it will be possible to add it to GirCore with GNOME 49.