Since its birth, Krita has been depending on ImageMagick (or the GraphicsMagick fork). The original idea was to build Krita as a GUI on top of ImageMagick. When the current team (or at least its veterans) started to work on Krita, ImageMagick was only used for exporting and importing files.
But using an abstraction of file formats did not give us enough control on how the files are loaded and saved, so four years ago, we decided to have our own implementation of the most used file formats: png, jpeg and tiff. Then later, tired of having to adjust our code for each releases of ImageMagick, we turned to GraphicsMagick, a fork that claim to have API stability. But the long term plan has always being to remove the dependency, and to have our own implementation of the file formats (or to use libraries when relevant).
Things have been accelerated recently, when we discovered that recent version of GraphicsMagick crashes Krita in a very weird way, so we decide to remove the GraphicsMagick files filter, and to finish implementing the format ourselves. This has started with the PPM filter that was finished yesterday, and now I am taking care of the JPEG 2000 format using the OpenJpeg library. But this might mean that in the near future, some important file format such as Photoshop’s PSD or Gimp’s XCF will not be available (but there is a Gimp plug-in to export to ORA which can then be imported in Krita).
Wait, there is no such thing as “libpng” or “libtiff” to use and share with GIMP and others? Isn’t it a huge waste of human resources to not share this code?
PS: Honest question, I simply wonder why your don’t use libs maintained by others. For example, digikam is probably also using some png/jpeg/tiff lib.
Maybe the guys from digikam can help!
Of course there is, and we use those libraries (libpng, libtiff, libjpeg, openexr, poppler and now OpenJpeg, and probably in the future ungif). The only formats for which we do not use a library are “simple” format like ppm or bmp.
What we do not use anymore is a kind of “abstraction layer” between those low-level libraries and krita, because it has proven difficult to maintain, and do not give use the kind of flexibility and power that we need.
Didn’t Lukas just discover with the spray brush stuff, that QT can load PSD and XCF’s in natively? Even if its without layer separation, surely that’s got to be better than no PSD/XCF at all…
PS Congratulations on finishing your thesis!
Actually, come to think of it did v2.0 / v2.1 even support PSD / XCF?
open source really needs project managers as i see.
Of course thank you for all your hard work but this is quite big regression.
I hope PSD and XCF won’t be missing for too long, they’re important. Otherwise, kudos for moving in what seems to be the right direction.
Well actually it is KDE, but it is very limited, I would feel better to have a FAQ to explain how to convert such a file using external tool in something that Krita can read. After all the Gimp has a plugin for ORA file and can read XCF and PSD, I would have no shame in telling that you have to use the Gimp to convert the file
Of course the long term solution would be to have good filters for those too.
Basic layered xcf is back already. Calm down people.
Only if you had the exactly right version of GraphicsMagick, i.e., 1.1. And in a very limited way.
Well, I think Cyrille and I are managing the transition quite well
. We won’t release a 2.2 without support for psd, xcf or gif; and for 2.1 nothing has changed compared to 2.0.