It would be nice to be able to support native formats used by open source image applications like GIMP (.xcf) and Krita (.ora). With .ora (OpenRaster), it is a format currently in development by the GIMP and Krita teams and is based on ODF. List of apps that support ORA - DrawPile, GIMP, Krita, LazPaint, MyPaint, Nathive, Pinta, XnView, Scribus
Yeah - completely valid request. Marking as NEW.
I see that the OpenRaster specification is hosted on freedesktop.org. http://www.freedesktop.org/wiki/Specifications/OpenRaster/
In the past some requests for formats like webp, jpeg2000 etc. have been closed as wontfix, so I think it would be good to re-evaluate this.
Don't think we have to add filters for every format. GIMP and Krita are tools for a different purpose and have powerful export filters itself so compatibility is granted. Even the ORA format is IMHO out-of-scope.
Conversely, if the image format is well spec'd, or better a license appropriate conversion library is available *and maintained* for filter use, why shouldn't we opt to read and bring in other graphic/raster formats--ORA (or KRA), XCF, HEIC, AVIF? Obviously some should be extensions, and we are not implying we would provide export filter for the formats. Only an ability to flatten as needed and read in as BMP.
If this is going to be implemented as extension it's welcome. But as fully maintained import/export filter it's way too much effort for a feature being almost (in my opinion beyond the threshold) out of scope.
We don't support adding new image formats as extensions AFAIK. It is also problematic as I don't think a document rendering should depend if a extension is installed or not (same with fonts, but at least the fonts can be bundled with the document). Supporting ORA and XCF IMHO doesn't make sense for different reasons. They are very complex formats that can contain many things than just a simple raster - like multiple layers that can be blended in various ways into the final image and things like support for higher bit depth (32bit floating point) and color spaces (CYMK). If we want to support such formats we would need to implement those features just to properly show the final raster image - better not. LibreOffice is not a raster editor so we should only support formats that are meant to hold raster images in its finished form. I'm sure we will add support for AVIF down the road, and hopefully also JPEG XL when the time is right for those two (more support and better tooling available).