We operate and develop a digital preservation system. One of our users has TIFF files, which Pillow's FliImagePlugin identifies as FLI/FLC files. I can not share these files, but I can give you some details of them.
What did you do?
Here is a simple test code
import PIL.Image
image = PIL.Image.open("testfile.tiff")
print(image.format)
print(image.get_format_mimetype())What did you expect to happen?
The output should be
What actually happened?
The output is
What are your OS, Python and Pillow versions?
- OS: Fedora 42 (a container)
- Python: Python 3.13.7
- Pillow: main branch compiled/installed from soure
--------------------------------------------------------------------
Pillow 12.0.0.dev0
Python 3.13.7 (main, Aug 14 2025, 00:00:00) [GCC 15.2.1 20250808 (Red Hat 15.2.1-1)]
--------------------------------------------------------------------
Python executable is /home/vvainio/scratch/Pillow/venv/bin/python
Environment Python files loaded from /home/vvainio/scratch/Pillow/venv
System Python files loaded from /usr
--------------------------------------------------------------------
Python Pillow modules loaded from /home/vvainio/scratch/Pillow/venv/lib64/python3.13/site-packages/PIL
Binary Pillow modules loaded from /home/vvainio/scratch/Pillow/venv/lib64/python3.13/site-packages/PIL
--------------------------------------------------------------------
--- PIL CORE support ok, compiled for 12.0.0.dev0
--- TKINTER support ok, loaded 8.6
--- FREETYPE2 support ok, loaded 2.13.3
--- LITTLECMS2 support ok, loaded 2.16
--- WEBP support ok, loaded 1.5.0
*** AVIF support not installed
--- JPEG support ok, compiled for libjpeg-turbo 3.1.0
--- OPENJPEG (JPEG2000) support ok, loaded 2.5.3
--- ZLIB (PNG/ZIP) support ok, loaded 1.3.1.zlib-ng, compiled for zlib-ng 2.2.5
--- LIBTIFF support ok, loaded 4.7.0
--- RAQM (Bidirectional Text) support ok, loaded 0.10.1
--- LIBIMAGEQUANT (Quantization method) support ok, loaded 4.2.2
--- XCB (X protocol) support ok
--------------------------------------------------------------------
Additional information
In hex code, our example image starts like this:
4949 2a00 12af cb02
Probably due to software used to produce these files, the TIFF IFD location has 0x12 as byte 4 and 0xAF as byte 5 in the file. This is enough to have FliImagePlugin consider it an FLI file. Byte 14 is 0 (and so are bytes 20-22, even though those are checked outside of _accept()). Bytes 14 and 20-22 are already image data of strip 1, so they are outside the TIFF header.
The FLI and FLC detection syntax in file/libmagic (here https://github.com/file/file/blob/master/magic/Magdir/animation#L878) checks that byte 12 is always 8, as in 8-bit colour depth. That check would be enough to differentiate these TIFFs from FLIs/FLCs.
The page https://www.compuphase.com/flic.htm says about this about the type field in the FLI/FLC file header:
"0xAF11 For FLI files
0xAF12 For standard FLC files (with an 8-bit colour depth)."
Checking for 8-bit colour depth would work here, because Pillow does not seem to support types 0xAF44, 0xAF30 or 0xAF31 at all. I'll add a PR about that.
Checking for the reserved areas of the FLI/FLC file would make the detection even better. You already check for bytes 20-22 in _open(). The other reserved areas are in offsets 48-72 and 80-120. These checks can not be made in _accept(), because the _accept() prefix is only 16 bytes long, so they would not solve this issue.
One option would be to increase the priority of detecting TIFF files. I'm quite certain there are more TIFF files than FLI/FLC files around. Could you consider adding TIFF as a format to preinit() in Image.py? Or is there some other way to control the priority?
We operate and develop a digital preservation system. One of our users has TIFF files, which Pillow's FliImagePlugin identifies as FLI/FLC files. I can not share these files, but I can give you some details of them.
What did you do?
Here is a simple test code
What did you expect to happen?
The output should be
What actually happened?
The output is
What are your OS, Python and Pillow versions?
Additional information
In hex code, our example image starts like this:
4949 2a00 12af cb02Probably due to software used to produce these files, the TIFF IFD location has 0x12 as byte 4 and 0xAF as byte 5 in the file. This is enough to have FliImagePlugin consider it an FLI file. Byte 14 is 0 (and so are bytes 20-22, even though those are checked outside of
_accept()). Bytes 14 and 20-22 are already image data of strip 1, so they are outside the TIFF header.The FLI and FLC detection syntax in file/libmagic (here https://github.com/file/file/blob/master/magic/Magdir/animation#L878) checks that byte 12 is always 8, as in 8-bit colour depth. That check would be enough to differentiate these TIFFs from FLIs/FLCs.
The page https://www.compuphase.com/flic.htm says about this about the type field in the FLI/FLC file header:
"0xAF11 For FLI files
0xAF12 For standard FLC files (with an 8-bit colour depth)."
Checking for 8-bit colour depth would work here, because Pillow does not seem to support types 0xAF44, 0xAF30 or 0xAF31 at all. I'll add a PR about that.
Checking for the reserved areas of the FLI/FLC file would make the detection even better. You already check for bytes 20-22 in
_open(). The other reserved areas are in offsets 48-72 and 80-120. These checks can not be made in_accept(), because the_accept()prefixis only 16 bytes long, so they would not solve this issue.One option would be to increase the priority of detecting TIFF files. I'm quite certain there are more TIFF files than FLI/FLC files around. Could you consider adding TIFF as a format to
preinit()in Image.py? Or is there some other way to control the priority?