Version: 0.8.1 (using KDE 3.4.2 Level "b" , SUSE 10.0) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.13-15.8-default when correcting image orientation according to EXIF information, the raw images (i.e. *.NEF) are also rotated, but not lossless. They are shrinked to ~ 50kb, when the original size was ~ 6MB. This way, they are destroyed, which should not happen with raw images, IMHO. IMHO, raw images should not by touchedby this function.
*** Bug 122697 has been marked as a duplicate of this bug. ***
This is not relevant of digikam itself but jpeglossless kipi plugin. A new test must be done before to perform rotation/flip to detect RAW file format. Actually the code test if file is JPEG and use libjpeg to process operations, else it uses QImage. This is a critic problem, because NEF files are detected like tiff file by QImage, and in this caseQImage will perform rotation on TIFF thumbnail from NEF file ! Gilles Caulier
I toogle to critic this file because NEF images are completly loss if jpeglossless running on ! Gilles Caulier
Next week, i will disable QT rotating action used to other file formats than JPEG, because all 16 bits image format less color depth (TIFF, PNG) and some RAW files based to TIFF/EP (NEF for example) are completly _BROKEN_. An alternative to Qt to manage 16 bits images properlly is to using ImageMagick in the plugin with others file formats than JPEG. What do you think about ? Gilles Caulier
It sounds good for me, morever ImageMagick is already needed for other plugins. Now the question how much do you take for new implementation? (to schedule new release) Angelo
Warning : other plugins like Batch process Images use Image Magick without a linking depency. IM is started like a new command line process. JPEGLossLess cannot use this way because all implementation use separate thread to perform rotation. This is want mean that we need to use a new depency with image magick library. Another way can be use here : using the host application to perform rotation/flip operations on other image file formats that JPEG. In digiKam core we have an new API to manage 16 bits images, but this way can be use only if a new method in libkipi is added. I'm not sure if this way is better (in all case, libkipi can be changed after to have release kipi-plugin in 0.1.0). Gilles
I see, well you're right the quick way is probably to use IM dev instead of leaving host applications implementing their own functions and of course that is not possible before 0.1.0. So imo you can go on. One more thought, I believe having an external and tested library to use sometimes it's better than implementing a proprietary one, at least to maintain :) OTOH if the library is buggy.... Angelo
ok, but this is want mean to add an new depency to ImageMagick library for linking. I want to have the others host application authors viewpoints before to do something like that... It's an important change... Gilles
> I want to have the others host application authors viewpoints before to do something like that... It's an important change... Infact it was *only* my opinion ;), anyway i don't get why it should be a problem for the host applications, I mean the kipi-plugins from the distros point of view is a stand alone package, with its build dependency and its executable dependency. So it should be rebuilt using IM-dev. Who install the package needs only IM/IM libraries (not the devel one), but that is already needed, as you just said, by other plugins. Host applications don't need to know it, just inherits it using the plugin. Angelo
SVN commit 536339 by cgilles: JPEGLossLess kipi plugin : disable Qt API method to rotate/flip/convertB&W non JPEG files else RAW/TIFF/PNG 16 bits images are broken ! This is want mean that only JPEG files will be processed by this plugin. To solve this problem, Image Magick API need to be used in this place instead Qt API. Nota : this B.K.O file can be toggle from critic to normal. CCMAIL: kde-imaging@kde.org CCBUGS: 123499 M +3 -1 convert2grayscale.cpp M +3 -1 imageflip.cpp M +3 -1 imagerotate.cpp --- trunk/extragear/libs/kipi-plugins/jpeglossless/convert2grayscale.cpp #536338:536339 @@ -67,7 +67,9 @@ } else { - if (!image2GrayScaleQImage(src, tmp, err)) + // TODO : B.K.O #123499 : using Image Magick API here instead QT API + // else RAW/TIFF/PNG 16 bits image are broken! +// if (!image2GrayScaleQImage(src, tmp, err)) return false; } --- trunk/extragear/libs/kipi-plugins/jpeglossless/imageflip.cpp #536338:536339 @@ -68,7 +68,9 @@ } else { - if (!flipQImage(src, tmp, action, err)) + // TODO : B.K.O #123499 : using Image Magick API here instead QT API + // else RAW/TIFF/PNG 16 bits image are broken! +// if (!flipQImage(src, tmp, action, err)) return false; } --- trunk/extragear/libs/kipi-plugins/jpeglossless/imagerotate.cpp #536338:536339 @@ -69,7 +69,9 @@ } else { - if (!rotateQImage(src, tmp, angle, err)) + // TODO : B.K.O #123499 : using Image Magick API here instead QT API + // else RAW/TIFF/PNG 16 bits image are broken! +// if (!rotateQImage(src, tmp, angle, err)) return false; }
SVN commit 536574 by cgilles: kipi jpeglosslessplugin : - using ImageMagick C++ API to perform action in non JPEG image. 16 bits images are preserved now. - Do not handle RAW files type to perform action. - Add libMagick++ depency. - Remove libTiff API. - Simplify file name in dialog. No need the complete filepath here to prevent large dialogs size. Nota : a libMagick++ API detection is require into kipi-plugins .configure file. CCMAIL: kde-imaging@kde.org, digikam-devel@kde.org BUG: 123499 M +4 -3 Makefile.am M +52 -39 convert2grayscale.cpp M +9 -11 convert2grayscale.h M +87 -107 imageflip.cpp M +10 -11 imageflip.h M +114 -102 imagerotate.cpp M +13 -12 imagerotate.h M +54 -34 jpegtransform.cpp M +54 -37 jpegtransform.h M +21 -15 messagebox.cpp M +12 -12 messagebox.h M +94 -83 plugin_jpeglossless.cpp M +11 -9 plugin_jpeglossless.h M +9 -9 progressdlg.cpp M +8 -5 progressdlg.h M +23 -63 utils.cpp M +10 -17 utils.h