[Gimp-developer] Maintaining buffers in a custom format in GIMP for EXR support



Hi all

This is a description of a way for the file-exr plug-in to create a
buffer in GIMP with the OpenEXR source data retained exactly. It could
also be used by other file formats to retain exact source data in the
gegl buffer. It seems like hack to me, so I'm sending it here for
discussion.

A GIMP plug-in runs as a different process from the GIMP app. So any
gegl/babl formats/conversions it creates is limited to that plug-in's
address space. The GIMP app doesn't know about it.

The app needs to be aware of the format in which a buffer's data is
passed from the plug-in to the app. It has to create a BablFormat for it
inside the app. The plug-in knows about the format and it has to pass
this to the app.

A libgimp function call to setup the formats in both the app's and
plug-in's address spaces respectively is a consistent way to achieve
this. The plug-in can pass chromaticities as args to this
function. There has to be a way to associate these two formats in the
app and in the plug-in respectively, and it could be the format's
name. The format's name would have to be automatically generated so that
it is unique for every set of chromaticities. A simple counter in the
format's name would be sufficient make such unique names such as "GIMP
format %u".

No processing code (except operations such as crop and external/file)
would process data in these custom formats. No processing code would
look up these formats by name, but they would request a buffer in the
formats they are aware of, i.e., in the working space of the operation.

Because babl has no support for chromaticities, GIMP would need to
provide extension code to babl, that can convert these custom formats to
a working space by maintaining a map from the format's name to a struct
chromaticities and registering additional conversions with every format,
where the format name is passed as user data. Such extensions may last
for the lifetime of the app process.

When babl gets support for creating formats with chromaticities as in
the roadmap, this last step can be removed.

Does this sound reasonable?

                Mukund

Attachment: pgpS9VMZOJ753.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]