Metadata (EXIF, color profiles, etc etc)

[FLIF-hub]

I have the following idea on how to add support for metadata: A FLIF file is either a "bare" image file, or it is actually a .tar (or some other archive format) which contains files with standardized names, e.g. _image.flif, _meta.gz, _colorprofile.gz, browser_hints.gz. This would make it easy to add arbitrary information (just add a custom file to the archive) and manipulate or remove the metadata.

So basically the .flif file would only contain the information needed to decode the pixels, and anything else (including information on how to interpret the pixel values, like gamma etc) would be in those optional extra files.

Would that be a good idea?

[haasn]

@eeeps This sounds like the ideal use case for a custom chunk that is understood by the server. Do you see a use in standardizing such information in FLIF itself, or would it be better to let nginx/apache etc. have their own understood formats for translating client requests to delivered offsets? (Since it seems like this would be a server-side thing)

[eeeps]

Looks like the tRko header in 6079da5 is exactly what I’m asking for, yeah?

Anyways, @haasn, by “own understood formats”, I assume you mean a wrapper-container, or sidecar files, or something that the server creates when it first sees a FLIF, to prepare it for responsive delivery. I think it's simpler if a FLIF is just a FLIF. If applications need, or don’t need, the optional header, they can add or purge it them themselves. But that metadata lives in the file.

Also, it’s not just servers who might need this... if browsers adopted sophisticated new loading mechanisms like this, they could make intelligent range requests from a dumb server — as long as this info is in the front of the FLIF.

[haasn]

@eeeps I specifically meant “own understood formats” for a chunk, but it seems like tRko covers that use case in a standardized way anyway. Probably a better idea to have a common solution here anyway, to avoid fragmentation.

I have no major objections to the current revision and it covers my use case, so that's all from my side I guess. Happy to see the move towards a simpler format.

[jonsneyers]

Closing this issue now, since we are done with defining the chunk structure. New issues can be opened if anyone wants to propose new chunks or other metadata-related stuff.