PureBasic Forums - English

JPEG and TIFF files can store metadata. So does the embryonic WebP format. PNG can also hold metadata (although it's not standardised).

I wonder if PB's SaveImage() command could be enhanced to pack metadata into an image file?

There could be a native structure with many possible fields (copyright, author, dates, subject etc.) and PB would pack in whatever fields the target format accepts. When calling SaveImage, an optional pointer to the structure could be included.
I personally would find this very useful.

Aside from the obvious benefit (metadata in PB-saved images), this would also mean we'd have a standard PB metadata structure. This structure could be used by library-writers when they write saving procedures for other formats (for example, I could use it in PureSVG). The structure could also have audio and video fields for people writing programs that save those kinds of files. (If PB ever has SaveVideo() or SaveAudio() commands, they could refer to the structure too.)

LoadImage() could also be enhanced with an optional pointer to a metadata structure. If the pointer<>0 and the loaded image contains metadata, it gets piped into that structure.

I hope the PB team consider this.

I think that's a good idea but it won't be integrated because everything is so unstandardized. Jpg -> Exif? Png -> strange comment tags? MP3 -> ID3, Ape? ...

I'm only asking for it for the formats that PB can save to (and that store metadata).

That's JPEG, JPEG2000 and PNG. Personally, I'd ignore PNG since there is no standard for PNG metadata.

When/if the WebP format takes off, I think it'd be very wise to add support for it (and its metadata capability) to PB. If the team add SaveAudio() and SaveVideo() commands in the future, they can worry about the metadata schemes for ogg, mp3, avi and WebM at the time.

But for now, this feature request would only affect two formats: JPEG and JPEG2000.

I've just realised it would also affect TIFF and TGA. PB can't save those formats but it can load them. So if LoadImage() loads the metadata, those two formats would need to be supported. TIFF uses the EXIF scheme, I don't know about TGA.

Seymour Clufley wrote:TIFF uses the EXIF scheme, I don't know about TGA.

It's the other way around. EXIF uses TIFF and JPEG. EXIF isnt a part of the TIFF and JPEG specifications. The EXIF specifications just use the TIFF and JPEG specifications. It could think of a EXIF lib for PB.

Thanks for the clarification, Thorium.

The trouble is, EXIF is not a universally used scheme. You could just as easily choose the XMP scheme, for example.

I do think that PB should have metadata read/write capabilities. But I don't think a dedicated library is the way. Say there was a command InsertEXIFMetadata(), and another one InsertXMPMetadata(). How many commands would there be in the end? One for every metadata scheme? And will each of these commands accept a different structure - PB_EXIFStructure, PB_XMPStructure, PB_DublinCoreStructure...

I think the simplest way to implement metadata read/write is the one I propose: have it built into existing commands like SaveImage and LoadImage. If PB continues to grow (in terms of media functions), one day it will probably have LoadAudio, SaveAudio, LoadVideo and SaveVideo commands. A separate metadata library would mean we'd have to use SaveImage, then open the file again with the metadata lib, insert metadata, and close it again. The same with audio and video files. Wouldn't it be better to have the metadata stuff integrated so that the file was only opened once?

Seymour Clufley wrote: I think the simplest way to implement metadata read/write is the one I propose: have it built into existing commands like SaveImage and LoadImage. If PB continues to grow (in terms of media functions), one day it will probably have LoadAudio, SaveAudio, LoadVideo and SaveVideo commands. A separate metadata library would mean we'd have to use SaveImage, then open the file again with the metadata lib, insert metadata, and close it again. The same with audio and video files. Wouldn't it be better to have the metadata stuff integrated so that the file was only opened once?

Building all possible meta data schemes into the existing libs would be overkill. Way to much work and would bloat the libs. Better do it with a plugin system, the same way image formats are added to the libs. And it should only support a few very famous schemes. If you need more you could write your own plugins.

In the same context a SaveToMemory function would be nice.