Version: 2.3.0 (using KDE 4.7.3) OS: Linux When resizing a PNG file with transparency the result image is corrupted in digikam main interface. That's valid for digikam image editor, digikam batch manager resize tool. But if you open the resulting image with gimpo or other viewer it's ok! Reproducible: Always Steps to Reproduce: Try to resize this logo to 180px: http://www.lyngsat-logo.com/hires/ss/sky_uk_movies_modern_greats.png with digikam IE or Batch queue resize tool Actual Results: The resulting image is ok but it is whown corrupted in digikam (if you open it in gimp og gwen it'sok) Expected Results: the image is resized and the transparency is shown correctly OS: Linux (x86_64) release 2.6.37.6-0.7-desktop Compiler: gcc
Do you use simple resize mode or restoration mode ? Gilles Caulier
In normal and restorations modes, using your test image and Showfoto 2.3.0, i cannot reproduce the problem. Alpha channel still here. In digiKam Image Editor do you use versionning ? If yes, by default JPEG format is used to archive version, and JPEG do not store alpha channel Gilles Caulier
I tested too Batch Queue Manager, and Alpha channel is preserved... Gilles Caulier
Ok, i can reproduce the dysfunction. It's not resize tool, it's thumbnail and preview mode which cannot display aplha channel properly. I can reproduce the problem with original PNG image. Just try to open it in preview mode (F3) Gilles Caulier
ok, I found the problem : In preview mode we don't display the full image, but preview JPEG embedded in IPTC metadata. There is no Alpha channel in this image. To render thumbnails, we use also the preview image from IPTC. To solve this issue, we must use a format which store alpha channel. To continu to use JPEG compression, JNG can be a solution, or PGF which use wavelets compression. Gilles Caulier
The problem also arises if the image is stored as a JPEG: apparently, the PNG has pixels with 0 alpha but non-null RGB, as a left-over from its creation. When the image is "converted" to RGB by simply truncating the alpha channel, these reappear.
As we store the preview in JPEG, it seems better not to store a preview at all if there is transparency. We'd need to blend on white, the image may be altered significantly by this.
Marcel, Another alternative is to store preview in another format supporting alpha, as JNG, which is JPEG +alpha for the web. image codec is in libpng : http://en.wikipedia.org/wiki/JPEG_Network_Graphics Another possible format is PGF for ex... Gilles Caulier
But would any other software than digikam be capable to use this preview?
they can, if we specify the image format in dedicated IPTC tag. look here : https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/master/entry/libkexiv2/kexiv2image.cpp#L864 none JNG or PGF are registered in Iptc.Application2.PreviewFormat. look format list given by exiftool by tag "ObjectPreviewFileFormat" : http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html We can registered new value as 100 or 1000 with JNG of PGF to be sure to not be in conflict with another one. Note : why not to migrate preview data from IPTC to XMP now, exemple into digiKam namespace ? We can do what we want into it (:=))) Gilles Caulier
Git commit 8b2e921abf7ed0a38a3ac5318c88e58e775a7068 by Marcel Wiesweg. Committed on 27/11/2011 at 21:23. Pushed by mwiesweg into branch 'master'. Provide methods to remove an alpha channel from an image. Remove alpha channel before saving to JPEG. - hasTransparentPixels checks if, given there is an alpha channel, some pixels actually is transparent (alpha < 1.0) - bitBlendImageOnColor allows to compose an image over a constant color This is equivalent to create a DImg, fill it with a color, blend the first image over the new one, and replace the first image with the result. - removeAlphaChannel blends the image on a color, usually, white, and removes the alpha channel - in updateMetadata: ensure that the previous embedded preview is always removed only add a new check that a preview is only added if the original image is significantly larger than the intended preview size To be discussed and currently unchanged: handling of transparent pixels CCBUG: 286127 M +189 -25 libs/dimg/dimg.cpp M +32 -0 libs/dimg/dimg.h http://commits.kde.org/digikam/8b2e921abf7ed0a38a3ac5318c88e58e775a7068
Git commit 4543c0c0281379ced0be448665081a33fd0cac80 by Marcel Wiesweg. Committed on 20/02/2012 at 12:33. Pushed by mwiesweg into branch 'master'. Disable creation of a preview for images with transparency until a solution involving a better file format is available. M +2 -1 NEWS M +6 -1 libs/dimg/dimg.cpp http://commits.kde.org/digikam/4543c0c0281379ced0be448665081a33fd0cac80