Hi all In the babl roadmap, there is the suggestion of a babl_define_named_rgb_space() proto that takes the chromaticities to create a babl format. This looks like a good idea, but I have a couple of questions regarding it: 1. A GIMP plug-in's address space is different from the GIMP host application's. After a file plug-in is done reading data into the app, it is terminated. If a babl format is created using a function such as above, how will a plug-in be able to pass a buffer to the host app, so that the buffer's format in the host app has corresponding chromaticities to what the plug-in had? 2. Assuming that processing operations want to work with buffers with known input formats and return a buffer with a known output format, do all such formats with custom chromaticities require naming? Would it not be sufficient if babl knew that the buffer was in an anonymous format with these associated chromaticities and knew how to convert it to a well-known format that a processing op would request (such as "RGB float")? i.e., the format is never looked up by name once it is created. These questions rise out of the OpenEXR format that Houz and I were looking at this week. There doesn't seem to be a way to pass the original source data as it exists in the EXR file and associated chromaticities from the plug-in to the GIMP app. (The GIMP app could repeat creating a babl format in the host app for the plug-in by having the plug-in pass the chromaticities using libgimp* function calls, but there should be a way to avoid having the plug-in repeat itself. Rather than calling babl directly, perhaps it may have to create a babl format using libgimp.) Mukund
Attachment:
pgpOBLbavl4Dj.pgp
Description: PGP signature
_______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
