Version: 0.8.1 (using KDE KDE 3.5.2)
Installed from: Fedora RPMs
GIMP files (.xcf) are quite big, but GIMP transparently handles compression if you use .gz or .bz2 compression.
showfoto, though, refuses to open .xcf.(gz|bz2) files, as it complains about having no handler - though it can open .xcf files.
Possibly this defect will exist in other parts of KDE too...?
Gnome handles this correctly, but KDE does not. Would be nice if it did, and particularly if Digikam would display thumbnails for such files. Don't know how Gnome does it but it is suprisingly fast to display a thumbnail even for a 50 or 100 MB xcf.bz2.
Seems that the situation has not changed since 2007. Neither .xcf.bz2 nor .xcf.gz can be viewed.
System: Open Suse 11.0, KDE 3.5.9
The question is: Why would someone do this? Why show / edit GIMP files with showFoto? It doesn't make sense to me...
I thought showFoto was the part of digikam which views the files. I guess I was wrong, begging pardon. So, which bugzilla should I use if digikam can not open such files?
No, you are not wrong... maybe I was too harsh now :-) Sorry.
But in general showFoto is used to edit images, it is mainly a standalone version of digiKam's image editor. Sure you can use it as a viewer, but I think there are better applications for that case, like Gwenview (if you are using KDE) or even Dolphin, KDE's new file manager.
Maybe I'm wrong here but I guess we will never support this image format, since it doesn't make sense to edit such files. Sometimes I think we should use a different name for showFoto, since I think showing photos is not the main task...
will GIMP files be supported?
Oh well forget what I said, this doesn't answer your question at all.
So I just checked it with KDE3 and KDE4, both showFoto versions can display XCF files. Maybe you have to wait a little bit longer, since the files need some time to render.
You we're getting close to the point I initially meant. To make it clear, I am organizing my pictures with digikam. XCF files are treated like any other picture file - a thumbnail is shown and if you open the file, digikam will show a new window to manipulate this picture.
But if you take a file with an extension of .xcf.bz2 or .xcf.gz, no thumbnail etc. will be shown. Digikam simply does not known the format. But since it's only a compressed XCF, this is confusing from the users point of view.
So you see, I don't explicitly talk about showFoto because I only do interact with digikam and I guessed that the viewing/editing component of digikam is shotoFoto.
Yes, my posts yesterday where not that helpful :-) It was late and I was sleepy...
Anyway I have made the experience that displaying XCF files is often not satisfying, they look different if you use layermodes and layermasks in it, so it never made sense to me to display them in other programs than Gimp.
I rechecked it and you are right, xcf.gz files are not displayed. I just looked for normal xcf that is opened.
Maybe we need other opinions here.
This my viewpoint : i never use xcf.gz file... and i will never use it. So I will never implement this stuff personally.
I can only assist the users point of view that Meik assumed on 2008-11-11 02:07:05.
My personal work-flow uses almost always the two most professional programs for photos on Linux: Digikam and Gimp. I think this may be a very common thing - both try to reach professionalism.
Even if a xcf-file is not shown 100% correct - a thumbnail will always help to identify it in the collection. - The alternative might be to use F-spot... I don't think this is a good idea to neglect it in Digikam.
As Digikam/ShowFoto is not able to use layers one has to use a different program for some tasks. - But of course it is wanted to be able to see the resulting images in the collection! - Why should one use a collection manager if it can't handle the images in the collection?
Created attachment 50131 [details]
patch for compressed GIMP files
I attached a proposed patch for this issue. It is basically a new loader for compressed GIMP files that decompresses the image to a temporary file (using zlib library) and than loads the image using QImage loader.
The patch is based on digikam 1.2.0.
The only condition is that the extension must be .xcfgz, not .xcf.gz (digikam does not handle double extensions). The .xcfgz extension should also be added in 'Additional image file extensions' (MIME types settings).
Thanks for the patch. we will review it...
Thanks a lot for your work.
My problem is this: Suddenly we seem to support as a major file format .xcf.gz, but not .xcf. Why? Because .xcf is loaded by a QImageIO plugin, .xcf.gz is seemingly loaded by a custom loader, but in fact, it is a wrapper around the QImageIO plugin (QIMAGE file format).
There are a number of KImgIO plugins, http://websvn.kde.org/trunk/KDE/kdelibs/kimgio/
This would be the best place for this purpose!
Also have a look at
it may be possible to feed the compressed data directly via QIODevices in the XCF imageio plugin (provided in kimgio as well).
Can you update your patch to be compiled against Git/Master code ?
Created attachment 66900 [details]
patch for compressed GIMP files (for digikam 2.3.0+)
I've attached an updated version of the patch that should work with git/master
I've used this patch with digikam 1.9.0 and 2.3.0 without problems, although I
must admit that it's not the best solution. But I didn't have the time to dig
deeper into the KDE internals, so it was good enough for me.
As Marcel said in comment #13, .xcf.gz|bz2 support must be implmeented in KImgIO as well to share this feature with other KDE applications.
Created attachment 94019 [details]
patch for gimp xcf compressed images
I attached a patch for KImgIO that handles xcfgz / xcfbz2 images in KDE.
That should also solve the issue in digikam (hopefully, because I'm sick of recompiling
digikam on every new release and / or dist-upgrade :) ).
I tested it on a debian 8 using kde from sources. Please review it and let me know if
there are any problems.
Tudor, if possible, submit your patch to https://git.reviewboard.kde.org/
I wonder, how compression is handled for *.svg versus *.svgz? ... it is "supported" ... provided you can find svg files that conform to svg 1.2 tiny specification.
*** Bug 360806 has been marked as a duplicate of this bug. ***