[digiKam-users] Digikam .xcf saga
Locked
12
12
 
|
Hi, 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 ? After all, we are in open source, and i know that XCF code is present and visible in Gimp implementation, but i would to be a little bit critic here, as XCF can be only loaded by Gimp and that all (i don't talk to be written by another application). 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. 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... Best Gilles Caulier Le lun. 23 sept. 2019 à 09:34, <[hidden email]> a écrit : On 9/22/19 10:50 PM, Maik Qualmann wrote: |
|
|
Gilles, if your sentence about XCF format is true, I'll not recommend GIMP
anymore. I can't understand how an open source application can create his own closed format. Is a nonsense. Precisely, I run away always from proprietary formats cause makes obsolete and unaccesible files when the years go by. Really, I left GIMP for Krita some years ago, cause Krita development is faster and developers (as Digkikam ones) have a very near feedback with users. Krita format (.kra) is rendered without problems by Dolphin. -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
On 9/23/19 11:35 AM, Rafael Linux wrote:
> Really, I left GIMP for Krita some years ago, cause Krita development is > faster and developers (as Digkikam ones) have a very near feedback with > users. Krita format (.kra) is rendered without problems by Dolphin. Hi Gimp and Krita, two softwares, two different uses/purposes Gimp: digital photo images editing/creating (like proprietary Photo$hop) Krita: digital painting => can't replace Gimp -- Maderios |
|
|
I'm sorry Maderios, but even if Krita was born to illustration, the fact is
that is more advanced than GIMP. In fact, Krita works with 16 bit color depth years ago (like any decent photo editing software should do) while GIMP adopt 16 bits last in version 2.10, few months ago!!! So, please, could you tell me something GIMP can do out-the-box that Krita doesn't (I know several things Krita does but not GIMP). Anyway, this is a Darktable forum, not about GNU/GPL photo editors. -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
I would say that this is digiKam mailing list... :-)
I can't say anything about comparing Krita and Gimp. Though, gimp 2.10 was released 2018-0427 with 16, 32 and 64(for some files) bits depth. Integer and float. Some 17 month ago. I agree that it took some time but a bit more than just month ago, as I interpret as 3-4... /Anders Den mån 23 sep. 2019 kl 22:13 skrev Rafael Linux <[hidden email]>: > > I'm sorry Maderios, but even if Krita was born to illustration, the fact is > that is more advanced than GIMP. In fact, Krita works with 16 bit color > depth years ago (like any decent photo editing software should do) while > GIMP adopt 16 bits last in version 2.10, few months ago!!! So, please, could > you tell me something GIMP can do out-the-box that Krita doesn't (I know > several things Krita does but not GIMP). > > > > Anyway, this is a Darktable forum, not about GNU/GPL photo editors. > > > > -- > Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
Yes, may 2018 ... too late for who want a professional workflow. I was working at 16 bits and color managing from more than 2 years ago with Krita, that let me choose CMYK color model when I print my photos, a "feature" that any professional photo editor program MUST have (we are in 2019, GIMP arrives too slow to the present). And NO, GIMP doesn't let create 64 bits color depth, only read it (FITS image format). Anyway, to read FITS format is not so interesting like work in HDR, like Krita can do in Windows (unfortunately, Linux lacks of this, but it's a Linux issue). We could continue, but not this is not the place, as I said previously El mar., 24 sept. 2019 a las 9:32, Anders Stedtlund (<[hidden email]>) escribió: I would say that this is digiKam mailing list... :-) |
[digiKam-users] Digikam .xcf saga_Gimp Bug report
|
|
In reply to this post by Gilles Caulier-4
Hi
I posted a bug report here about Gimp 2.10 XCF support https://gitlab.gnome.org/GNOME/gimp/issues/3990 -- Maderios |
|
|
In reply to this post by Gilles Caulier-4
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 |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |