Support for PIK, GPR and others

[DonaldTsang]

I would recommend prioritizing FLIF, FUIF, PIK and GPR, the others are there for completeness sake.

• Company free FOSS format
  - FLIF ("Perfect" format) https://github.com/FLIF-hub/FLIF
  - FUIF (JPEG backwards compatible format) https://github.com/cloudinary/fuif
• Corporate format
  • Google's PIK (FOSS Licensing format) https://github.com/google/pik
  • Go Pro's GPR (FOSS licensed format) https://github.com/gopro/gpr
• Other formats
  • SSDV (Robust JPEG compatible format) https://github.com/fsphil/ssdv
  • FRG ("fast" graphics) https://github.com/sisong/libfrg

[multiSnow]

https://github.com/multiSnow/mcomix3/blob/59e877fc1e8f0ecd23c170ae34acdafbee9089b3/mcomix/mcomix/lib/FlifImagePlugin.py

It is a decoding-only example of FLIF by using libflif or libflif_dec through ctypes.
As mentioned in comment, libflif is still using some global variables, so it would be not thread-safe to directly link into C module.

[DonaldTsang]

@multiSnow thanks for keeping the record, would hope the FLIF group can get their acts together. Could you decompose the software to pinpoint what is wrong with global variables?

[multiSnow]

It is already reported in FLIF-hub/FLIF#517 and seems to be fixed by FLIF-hub/FLIF#531, but still not merged.
The global variables appeared in https://github.com/FLIF-hub/FLIF/blob/master/src/common.cpp (grep TODO).

[DonaldTsang]

Status report?

[madeddy]

This issue should IMHO be closed to reduce junk and clutter in the topic lists.
Reason: Deprecated by reality

[radarhere]

https://github.com/FLIF-hub/FLIF

FLIF development has stopped since FLIF is superseded by FUIF and then again by JPEG XL

https://github.com/cloudinary/fuif

FUIF development has stopped since FUIF is subsumed in JPEG XL

Unless someone says otherwise, I'm going to take this to mean that adding support for those formats is no longer necessary.

[radarhere]

SSDV and FRG don't seem to be popular formats by any means. Is there a particular reason you would like support for them?

[madeddy]

He states the reason in the first line of the issue opener: I understand this as "because they exist". 😖

I got a possible crazy idea for the format enhancement issues: Why not make a (sort of) permanent issue for this? New and known unsupported formats could be listed/categorized there with a "state of things". Would surely reduce the clutter and workload in the issues somewhat.
Something like:

• Planned: avif, jpeg xl
• Watched: webp2
• Rejected: flif, fuif
• Outdated: tga

[radarhere]

https://github.com/google/pik now states

There is currently no development going on here. Parts of this project have been used in JPEG XL, which is under active development.

and

Note that the bitstream is still under development and not yet frozen.

https://en.wikipedia.org/wiki/JPEG_XL and https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL refer to PIK only as a "proposal".

So it's possible that this format never actually reached a point where it was intended to be used.

https://github.com/gopro/gpr states

The General Purpose Raw (GPR) is 12-bit raw image coding format that is based on Adobe DNG® standard

Given that, it seems sensible to group that format in with #6482

[radarhere]

If I understand correctly, SSDV is a subset of the JPEG format - meaning that SSDV images can already be read by Pillow.

It isn't clear if the request here was for reading or saving. It might seem reasonable to want Pillow to be able to open a lesser-known format for "completeness", as images can come from any source, but if the request is for saving, a stronger guarantee that it would be used would be helpful.

Closing. The GPR request can live on in #6842