[digiKam-users] Digikam .xcf saga

[Alexandre Prokoudine]

Hello,

There's a slight chance that I should stay out of it, but this is a
slow Friday, and I have some spare time on my hands.

> After reflexion about XCF support, i want to be clear. Even if somebody can
> hack XCF format by "reverse engineering", in KImageFormat, Krita, or
> ImageMagick , this will not be a long term support solution. Typically, the
> right question is :
>
> WHY GIMP DEVELOP A CLOSED FORMAT AS ADOBE ?

This is the public documentation of the file format:

https://gitlab.gnome.org/GNOME/gimp/commits/gimp-2-10/devel-docs/xcf.txt

The initial revision of it was done in 1997, that's 22 years ago. 22
years, Gilles.

In 2006, the documentation received a very cool update by Henning
Makholm. Since then, the docs have been updated for every major
release.

Latest changes in version 2.10 were documented less than a month after
the release, in May 2018. This is just one of those commits:

https://gitlab.gnome.org/GNOME/gimp/commit/517b5df70c7aaeb4a1b9015fcadcdae46190d3cb

More to the point, the actual KImageFormat's source code specifically
refers to the spec three times:

Let's have a look, you and me, together:
https://cgit.kde.org/kimageformats.git/tree/src/imageformats/xcf.cpp

1:

quint32 apply_mask = 9; //!< Apply the layer mask? Use 9 as
"uninitilized". Spec says "If the property does not appear for a layer
which has a layer mask, it defaults to true (1).
                                //   Robust readers should force this
to false if the layer has no layer mask.

2:

    if (layer.mask_offset != 0) {
        // 9 means its not on the file. Spec says "If the property
does not appear for a layer which has a layer mask, it defaults to
true (1).
        if (layer.apply_mask == 9) {
            layer.apply_mask = 1;
        }

3:

    } else {
        // Spec says "Robust readers should force this to false if the
layer has no layer mask."
        layer.apply_mask = 0;
    }

Like I said, three times, Gilles. The actual code you were supposed to
know about mentions the XCF spec and has quotes from it. Fancy that!

> as XCF can be only loaded by Gimp and that all (i don't talk to be written
> by another application).

Nope, XCF files can be loaded by more apps than GIMP. Lemme guide you
through this real quick.

KImageFormats: https://cgit.kde.org/kimageformats.git/tree/src/imageformats/xcf.cpp
(and thus anything that uses KImageFormats)

ImageMagick: https://github.com/ImageMagick/ImageMagick/blob/master/coders/xcf.c

Krita: https://github.com/KDE/krita/tree/master/plugins/impex/xcf

That's just off the top of my head.

Whether these projects have the time and interest to update their code
to read the latest version of XCF is a whole different topic. And,
given 63KB of spec as a text file, most likely nothing to blame GIMP
developers for.

They do have the documentation and they are welcome to ask questions
or tell us they think the documentation is incomplete. In that case,
we'll review and fix that (if a fix will be required).

> Seriously, make this puzzle unsolvable by 3rd
> party applications is a shame, and i know the reason from Gimp team : to
> have the full control of XCF contents in the long term.

Now, now. Conspiracy theory, eh?

> Typically, without
> exporting XCF read methods to a shared library, permit to developer to make
> a mess in code, when they want, and where they want... It's not a safe way
> used in Open Source world...
>
> Voilà this is my long development experience viewpoint...

What does your long development experience say about the performance
cost when using a library to read a file vs a native implementation?
We could have a nice chat about that too.

Or maybe we could talk how the project has almost 1900 bug reports in
the tracker, a major ongoing refactoring effort, and just three-four
major programmers (depending on whether GEGL developments counts in
your opinion), and how this affects chances of writing something like
libxcf. I would _love_ to hear your opinion about things volunteers
owe _you_ to do!

Not one single image editor or painting application on Linux that I
know of (and I know most of them, which is kind of my job) has a
library with public API to read and write its project files. Not one,
Gilles. Would you like to blame projects like Krita or MyPaint for
developing a closed format as Adobe, too? That would be a fun thread
to read!

So how about you reconsider your statement and apologize and then we
can forget it all and be nice chaps just like we used to?

Alex