I don’t know the gexiv API, but exiv2 proper has Exiv2::XmpParser::encode which gives you a nice std::string of the XMP content. Isn’t that enough? Or do you want to have all possible metadata flavours (Exif, IPTC, XMP, …) in a single blob? If yes, then I doubt it would be terrible useful as GIMP’s core can’t make any sense from that.
On the contrary, as far as I can understand the gimp_metadata_serialize function puts Exif, IPTC and XMP tags together into a single XML-formatted textual blob, see here.
This is then read back by the gimp_metadata_deserialize function.
This is (again as far as I understand, I’m not a GIMP code expert) how the metadata tags are stored into and retrieved from the “gimp-metadata-parasite” of XCF files.
Well, yes, but that’s a GIMP internal format. I wouldn’t try to assemble that manually. Instead I would (and do in file-exr) use gimp_metadata_set_from_exif and gimp_metadata_set_from_xmp. That feels more robust wrt. changes in how the parasite is handled in the future.
I’ve written an article about serialising metadata into memory buffers. http://dev.exiv2.org/projects/exiv2/wiki/Guidance_about_serialising_metadata_using_MemIo_and_ExvImage_Classes
I hope this helps. I haven’t really understood what’s really needed here. With good fortune, this will move you forward.
1 Like
Thanks! I will read it carefully.
I have also the idea to suggest the VIPS authors to replace libexif with Exiv2, because of the provided support for TIFF files and the existence of a GObject interface (GExiv2). In which case the serialisation will most likely be a necessary prerequisite…
Please tell the VIPS people that I will work with them to adopt Exiv2. And then I’ll try to persuade RT to use Exiv2.
1 Like
Ok. I will make a feature request on their github issue tracker, and post here the link so that you can follow the discussion and contribute if needed.
Moving RT’s metadata handling to Exiv2 would also be a great idea, in my opinion!
Robin, no need to convince me 
I really would like to switch RT to Exiv2!!! But I have to find some free coding time…
Ingo
Ingo. Oh, if there were 28 hours in every day, I would do this for RT. This week, I wrote the outline plan for Exiv2 v0.27: http://dev.exiv2.org/news/3 I’m sure you don’t have 28 hours in your days either. Maybe we’ll get lucky and an engineer will appear and she will integrate Exiv2 into RT. We’ll see. Best Wishes.
@clanmills I have submitted a feature request on the VIPS issue tracker about adopting Exiv2. Here is the link, so that you can follow the discussion and hopefully contribute if that will be accepted: https://github.com/jcupitt/libvips/issues/453
Also feel free to complete my small list of possible advantages, in case I forgot something relevant…
Have a nice day!
John and I have enjoyed an very thorough discussion about this. I still haven’t understood the work-flow, however I think we have it covered.
Hi Robin,
thanks a lot, I have followed the discussion with very much interest.
Let me maybe try to explain the VIPS-PhotoFlow workflow here:
VIPS is a node-based image processing system. Each node is represented by two entities: the operation, which provides the actual code that does the processing of the specific node, and the VipsImage, which contains all the meta-data (in a generic meaning) associated to the node output. The meta-data includes the image size, pixel format, number of channels, colorspace, as well as the associated ICC profile and the EXIF tags.
A node uses the informations contained in the operation as well as all the input and output VipsImages when it performs the pixels processing.
When loading an image from disk, an input node reads all the meta-data included in the input image (ICC profile, EXIF tags…) and puts them into its output VipsImage in the form of attached memory buffers. This is why one needs a way to serialise the EXIF tags into a single, contiguous memory buffer.
When a processing node is connected to the input one, the meta-data is transferred to the output VipsImage of the processing node, and so on for all the processing nodes in the pipeline.
Finally, when an output node is attached at the end of the pipeline, it reads the meta-data from its input VipsImage and writes it into the output file on disk. Here is where one needs to de-serialize the EXIF tags from the memory buffer attached to the VipsImage and insert them into the output image format.
I’m not sure if this really answers your questions, but it is hopefully a good starting point for further clarifications…
Well, I think we’re on the way to a happy place. I’m a little lost about who writes what. John clearly knows a lot about this. Between us we’ll get there. I’m hope to be code complete Exiv2 v0.26 in June and I have a plan for v0.27. I’ll add BigTiff and some other stuff we discussed to the trunk and it’ll ship in v0.27.
I hope things are good with you and yours in France. It’s Whit Bank Holiday in England and the weather is nice. Off to Scotland for a week’s vacation.
1 Like
Is it only EXIF tags that are included? Or does VipsImage also contains all original XMP properties, IPTC datasets, manufacturer makernotes and any other form of metadata from the original image?
@asp John (VIPS) and I have been discussing using a JPEG as the metadata container. That can store Exif, IPTC, XMP and ICC metadata (and other metadata). The container will have no graphics and will be embedded in the tiff for Andrea (@Carmelo_DrRaw) to access all metadata using libexiv2. I originally suggested using .exv for this purpose, however libjpeg doesn’t recognise .exv as a JPEG. Neither of us have bothered to investigate libjpeg’s fear of .exv.