The ImageFile node supports a wide range image formats:
bmp, cut, dds, exr, g3, gif, hdr, ico, iff, j2c, j2k, jif, jng, jp2, jpe, jpeg, jpg, koa, lbm, mng, pbm, pcd, pct, pcx, pfm, pgm, pic, pict, png, ppm, psd, ras, raw, sgi, targa, tga, tif, tiff, wbmp, xbm, xpm (from the file open dialogue).
That node also supports webp and jfif (and perhaps others) that don't exist in that list and one can open them by searching for '*'. However, if there are more webp or jfif files in the folder, one cannot cycle through them using arrow keys - the node does not see them.
This inability to see images not in that list extends to the ImageFolder node (assuming it can read all the image types that the ImageFile node can).
The Model node suffers from this file blindness too. Of course I have image and model files that I tend to use most often and image formats are easy to convert but this is something that would be nice to fix rather than asking for additions to the list.
File format compatibility
Re: File format compatibility
I’m not understanding how you would suggest to fix this other than adding the missing extensions?
Re: File format compatibility
Thanks for looking into it!
Just to clarify from my end (I'm not the programmer!): it seems like the file dialogue, folder selection, and arrow-key cycling all rely on the same hardcoded extension list. When I manually type * in the open dialog, it bypasses that list and lets the underlying decoder successfully open formats like .webp or .jfif, which proves the app's engine can read them. However, because folder selection and cycling don't have a * wildcard option, they fall back strictly to that hardcoded list and ignore those files.
I know from when I've asked for model extensions to be added in the past, manually updating that list enabled cycling for them—though models don't have a model folder node yet (useful for animation and the iterator).
Rather than having to keep manually updating hardcoded lists every time a new format pops up, would it be possible for the app to automatically check what formats the underlying libraries (like FreeImage or Assimp) support at startup, so the app populates its own lists dynamically?
Just to clarify from my end (I'm not the programmer!): it seems like the file dialogue, folder selection, and arrow-key cycling all rely on the same hardcoded extension list. When I manually type * in the open dialog, it bypasses that list and lets the underlying decoder successfully open formats like .webp or .jfif, which proves the app's engine can read them. However, because folder selection and cycling don't have a * wildcard option, they fall back strictly to that hardcoded list and ignore those files.
I know from when I've asked for model extensions to be added in the past, manually updating that list enabled cycling for them—though models don't have a model folder node yet (useful for animation and the iterator).
Rather than having to keep manually updating hardcoded lists every time a new format pops up, would it be possible for the app to automatically check what formats the underlying libraries (like FreeImage or Assimp) support at startup, so the app populates its own lists dynamically?
Re: File format compatibility
It seems obvious that those libraries should report what extensions they support, but they don’t.
An alternative solution would be to have the extension lists stored somewhere you can edit, such as in the preferences. The preferences persist when you install an update, so you’d only lose them if you manually reset or deleted them.
An alternative solution would be to have the extension lists stored somewhere you can edit, such as in the preferences. The preferences persist when you install an update, so you’d only lose them if you manually reset or deleted them.
Re: File format compatibility
Nicer within the app but from the config file just as useful. Just add one's faves and forget until you need it again.
Re: File format compatibility
On a related note, I did a quick test with .hdr and .exr files from Polyhaven (which are currently in the ImageFile recognised format list). They gave an 'invalid file' error when loading into Magic, but opened fine when tested in a standalone FreeImage viewer (Quick Picto Viewer) and Affinity 3.31.
Re: File format compatibility
Ok thanks. If FreeImage supports those, we might not be handling them correctly.