Hi, I am not sure how this bug may be related to #275400, but it happens to me that some files are shown in full size preview and others in reduced size, despite on the "album view" settings (settings/configure digikam/album view) i have selected "embedded preview loads full-sized images". Even when deselecting this option, I get the same behavior. The preview does not stay in one specific mode. It switches depending on the file. I have not found anything different among the files since they were taken with the same camera, format etc. The reduced-size preview, is blurry as mentioned on #275400 and also corresponds to an older version of the file. It seems like a thumbnail of the original file, prior the use of the editor (i.e. transforming/aspect radio crop..). I have cropped several images, but the reduced size preview still shows them prior their edition and very blurry. - I do want to fix the preview to full size but it does not hold. It keeps switching to full or reduced size without apparent reason and regardless of the embedded preview setting. - the symptom continues regardless rebuilding fingerprints and thumbnails. Reproducible: Always Steps to Reproduce: 1.in "album view" clic any file. 2.with some pics, the embedded preview is shown as full-sized, while with others is shown as "reduced-size" 3.to change settings of "Embedded preview loads..." does not change this behavior nor holds on a specific preview mode. Actual Results: some pics are shown in reduced-size preview mode, while others in full-size. Expected Results: the preview mode should stay fixed and always the same, regardless the file, depending only to the settings on "settings/configure digikam/album view/embedded preview loads full-sized images". For some of the pics files the only way I found to see in full size, is using the Editor. The light-table, slideshow, and the preview mode keep showing reduced-size, very blurry and not including the editions (like cropping) done to the files since they were downloaded the first time. - Hardware: ASUS/AMD Phenom + nVidia - OS: OpenSuSE 12.1 (linux 3.1.9-1.4-desktop x86_64) - GUI: KDE 4.7.2 (4.7.2) "release 5" - Digikam: 2.5.0 (built date Feb 3 2012)
Created attachment 70454 [details] preview-digikam.jpg Hello, I am not really able to replicate this bug. Could you attach a couple of screenshots of two photos being shown in "Full Size Preview" and "Reduced Size Preview" when "embedded preview loads full-sized images" is checked ? [Along with the properties frame open]. Varun Herale
Hi Varun, thanks so much for answering about this bug. Attached you will find the screen snapshots. for bnoth cases I confirmed that I have setup digikam to load the full-sized preview images. - Here you can see that it loads a reduced-size. - the reduced size is also blurry. Same under the light table, and slideshow. Only on editor and showphoto the images are shown correct. - you can check the versioning at right, and will see that the reduced size also is not including the changes to the original image. I do not know where digikam is "storing" the preview files - to attempt deleting them and may the preview will make them again... I even tried by deleting some home/user/.thumbnail image files to test if Digikam rebuild the preview images, but it does not. By rebuilding the thumbnails (under tool) or the fingerprints or saving to files the meadata, the problem is not solved neither. And these changes on the preview mode occur always with the same images. It is not random. But the images are all the same format etc. So, no idea what Digikam is taking into account to show different preview modes to some and not others... Please if there is anything else I can do to help, tell me. Thanks so much, gps G. Paolo Sanino OrcaTech Mobil: +56 9 78048113 E-mail: orcatech@vtr.net CP: 7640392 On 04/17/2012 11:25 AM, Varun Herale wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > Varun Herale <varun.herale@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |varun.herale@gmail.com > > --- Comment #1 from Varun Herale <varun.herale@gmail.com> --- > Hello, > > I am not really able to replicate this bug. > > Could you attach a couple of screenshots of two photos being shown in "Full > Size Preview" and "Reduced Size Preview" when "embedded preview loads > full-sized images" is checked ? [Along with the properties frame open]. > > Varun Herale >
Created attachment 70455 [details] preview-edit.jpg
Created attachment 70459 [details] preview-full.jpg If you can provide some test image files, it can help Varun to hack this entry. Note: code to manage Preview loading is here : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/previewtask.cpp#L195 Gilles Caulier
Hi Varun, Here are two attachments with the "properties frame opened". Again, some are previewed in full size while others in blurry-reduced-size, despite the embedded preview load settings (full size). regards, gps G. Paolo Sanino OrcaTech Mobil: +56 9 78048113 E-mail: orcatech@vtr.net CP: 7640392 On 04/17/2012 11:25 AM, Varun Herale wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > Varun Herale <varun.herale@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |varun.herale@gmail.com > > --- Comment #1 from Varun Herale <varun.herale@gmail.com> --- > Hello, > > I am not really able to replicate this bug. > > Could you attach a couple of screenshots of two photos being shown in "Full > Size Preview" and "Reduced Size Preview" when "embedded preview loads > full-sized images" is checked ? [Along with the properties frame open]. > > Varun Herale >
Created attachment 70460 [details] preview-reduced.jpg
Created attachment 70462 [details] DSC_3078_v1.JPG Varun, Take a look into source code, Preview size loading depend of screen size and the preview image size taken from file (delegate to libkexiv2/Exiv2) Gilles Caulier
Hi Gilles and Varum, Here you can find attached the same files used for the previous screen shots. gps On 04/17/2012 02:47 PM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > --- Comment #7 from Gilles Caulier <caulier.gilles@gmail.com> --- > Varun, > > Take a look into source code, Preview size loading depend of screen size and > the preview image size taken from file (delegate to libkexiv2/Exiv2) > > Gilles Caulier >
Created attachment 70463 [details] DSC_3079_v1.JPG
Created attachment 70466 [details] preview-reduced-no versioning.jpg Hi Paolo, Thanks for the images. I have one more question - Is the problem of "Reduced Size Preview" only occurring in edited images or unedited also ? Also, thanks Gilles for the link. I am looking into the code right now. Varun Herale
Hi Varum, Exactly that is the case. I just confirmed that the original files (not edited) are always previewed properly. However, the contrary is not always true. Only some of the edited images present the switching to blurry reduced size preview problem. Using the versioning tool, I was able to undo the changes of a file with problems, reverting it to the original status. Then the image started to be previewed properly. Then I edited cropping it, and saving it. That edited frame presented again the preview problem. So, it is something related to the changes that the file experiences when edited and saved. But not in all cases. One more detail is that I have some files presenting the problem, that were edited as well (mainly crop and/or gamma adjusts), but the versioning tool does not show the previous versions. However, the preview shows a blurry reduced size of the original photo. Like the attached screenshot. The original file had two dolphins. Then I cropped the image to one individual and saved it. Gwenview shows it properly, as well as Showphoto and Digikam's image Editor. However, Digikam's preview, slideshow and light table still shows the image with the two original dolphins... gps On 04/17/2012 03:42 PM, Varun Herale wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > --- Comment #10 from Varun Herale <varun.herale@gmail.com> --- > Hi Paolo, > > Thanks for the images. I have one more question - Is the problem of "Reduced > Size Preview" only occurring in edited images or unedited also ? > > Also, thanks Gilles for the link. I am looking into the code right now. > > Varun Herale >
Hi Paolo, Could you untick the "embedded preview loads full-sized images" option and check all the problem files again ? I think the problem is only with "Full Size Preview" option, so unticking must display expected results. Varun Herale
Hi Varum, sure. I just did it and with the untick of "loads full-sized..." the preview rolls back to full-sized preview. The images that were shown blurry and reduced-scale, became properly previewed. I am not getting the "autonomous" switch between the preview modes. Slideshow testing: now it looks normal. Now testing this on the light-table, the images still are shown in blurry reduced-size... checking the settings of light-table I fount selected the option "loads full-sized image". By unticking this option, the light-table recovers the full-size preview. So, the full-size preview feature is lost only when the setting options to load the images in full-size are selected (for light-table as well as album preview). gps On 04/17/2012 04:17 PM, Varun Herale wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > --- Comment #12 from Varun Herale <varun.herale@gmail.com> --- > Hi Paolo, > > Could you untick the "embedded preview loads full-sized images" option and > check all the problem files again ? > > I think the problem is only with "Full Size Preview" option, so unticking must > display expected results. > > Varun Herale >
Okay :) So the problem is with displaying when "embedded preview loads full-sized images" is ticked. I will start working on the code now. I will get back to you if I have any more questions. Also, the captions saying "Full Size Preview" and "Reduced Size Preview" are not based on whether the checkbox is ticked or not.. so it might be misleading sometimes! Varun Herale
Varun, that is the case. When the option for full-size image loading is selected on Album Preview's settings, some of the edited images are previewed in "reduced-size" mode, but presenting really a very blurry pre-edition version of the image. The captions are indeed showing the "autonomous" switching between the preview modes, being based on the resulting size preview rather than the loading settings. Same case with the captions for the Light-table. gps On 04/17/2012 04:46 PM, Varun Herale wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > Varun Herale <varun.herale@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 > > --- Comment #14 from Varun Herale <varun.herale@gmail.com> --- > Okay :) > > So the problem is with displaying when "embedded preview loads full-sized > images" is ticked. I will start working on the code now. I will get back to you > if I have any more questions. > > Also, the captions saying "Full Size Preview" and "Reduced Size Preview" are > not based on whether the checkbox is ticked or not.. so it might be misleading > sometimes! > > Varun Herale >
Varun, Another links in source code : Likexiv2 preview extraction interface : https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/master/entry/libkexiv2/kexiv2previews.h digiKam preview widget : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/digikam/views/imagepreviewview.cpp digiKam preview item : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/widgets/graphicsview/dimgpreviewitem.cpp#L67 The last one is very important. Look like size of preview is passed in this method to preview load thread, accordingly to screen size. Gilles Caulier
Hi Varun and Gilles, Not so good news... I just found an image with the same problem of blurry reduced-size preview, despite unclicking the full-size preview options... So, the changes on the settings almost got all the images previewed properly, but there is still something relying on the back. it looks just like the screenshot "preview-reduced-no versioning.jpg" but despite of the deselected preview options. gps
Hello, It appears that the preview is loaded correctly if the line 157 to 173 in - https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/dimg.cpp#L157 are commented out. Marcel, Does this block of code copy the original image instead of the present copy ?
Varun, Can you print if allocateData() return true or false ? Gilles Caulier
(In reply to comment #19) > Varun, > > Can you print if allocateData() return true or false ? > > Gilles Caulier allocateData() returns True.
Created attachment 70490 [details] Proposed patch Hello, I have made some modifications to previewtask.cpp. After testing with test cases, everything seems to work fine. Attaching the proposed patch.
Varun, Can you explain a little bit your fixes please ? Gilles Caulier
(In reply to comment #22) > Varun, > > Can you explain a little bit your fixes please ? > > Gilles Caulier Gilles, Using gdb I found that the image is previewed properly whenever it is loaded using "load()" function of DImg class before painting from - https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/widgets/graphicsview/graphicsdimgitem.cpp#L191 This happens only in certain cases where QImage to DImg conversion is done - https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/previewtask.cpp#L261 So I added another line to load after the conversion is done. This change affects only during preview of images. Varun Herale
Marcel, The image data stored while copying from QImage to DImg is for some reason not the expected data. But this conversion seems to work for all other cases except this one - so I didn't want try any changes to this. That is why I wrote lines to load directly from the file instead of from QImage. Where do you think the problem is ? Is this because QImage has wrong data ? Varun Herale
Varun: Have you been able to reproduce the problem with the dolphin image given above? I dont really see a difference between the preview and the same image opened in the editor. As we have switched to full-size preview, the second code path is relevant. As this is a JPEG, apparently the source of the QImage must be the preview, lines 307ff. That cannot really be the case, the preview in the image is clearly smaller then the current (deliberate) threshold of 0.48. Or is a preview loaded by KDCRaw in the lines below???
Created attachment 70520 [details] Image displayed wrongly Marcel, Please check with the image that I am attaching. This is one of the images with which I can reproduce the problem. For this image - the preview is not smaller than the threshold.. and only in these cases the problem is seen. So when this preview is copied into QImage and then converted to DImg -> the preview is not displayed correctly. Varun Herale
Marcel, Also, how come when certain images are edited their embedded previews are retained whereas if certain other images are edited their embedded previews are lost ? I don't get this part. It looks like for the images where embedded previews are retained -> they still represent original image. That is why there is this problem. Varun Herale
The attached image is quite clearly broken: It contains a preview which is larger than the files itself; obviously the file was cropped and the preview not removed. This is not a bug of the preview mechanism.
Yes Marcel, the problem is not with the preview mechanism. But this image was created after editing with the imageeditor, so the problem is with the imageeditor ? Also, I have tried editing some images of my own.. And none seem to retain their preview except these images. Varun Herale
Marcel, Since the camera used is Nikon, the embedded preview with tag "Exif.Nikon3.Preview" seems to be stored. But in the code, only Iptc Previews are deleted - https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/dimg.cpp#L2924 This is the root cause of problem here I think. The function can be changed to delete any tag with "preview" in it.. but is it right way to go ? Varun Herale
This is true. Andreas: We use exiv2's PreviewManager facilities to load previews. When editing and image and saving it, we need to remove the previews which show the previous contents. Currently, we remove Iptc.Application2.Preview*, Exif.SubImage1 tags for TIFFs and use ExifThumb to erase that one. Looking at the source, PreviewManager supports a much wider range including proprietary tags to extract previews. Is there a way to safely delete them (except for copying the current tag list from preview.cpp)?
Ideally, the Exiv2 PreviewManager should support delete and set preview operations where possible. However, when it comes to RAW images I'm not sure if that's always safe. Some of these previews may be considered an integral part of the image structure.
For our purposes, we only care about images which we create; because only when the image data is altered the old preview is invalid. That means we have ExifData, XmpData etc. in memory and need to edit them, removing all traces of invalid previews. So for now, we probably need to get a list of proprietary tags like the Nikon one mentioned above and remove them?
Created attachment 71630 [details] Corrupted preview after using Editor on a file created by nikon D3000 Hi, after the latest update I thought the bug was completely resolved. However, I just had the same problem again, associated to photos taken with a Nikon D3000. Maybe this camera stores the preview in a different way? I am attaching a file as a sample of the problem after using the Editor for cropping and saving, the preview got corrupted. thanks for the great work! gps
Official digiKam 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier
Hi Gilles, I have tried to install 2.6.0 but no luck. The Build Service only finds it under the Factory/snapshot repository, but after the one click install I get an error message: "valid metadata not found at specified URL / Repository type can't be determined". I tried downloading the RPM manually but I get dependencies not satisfied (libtiff....). From Digikam's website I get t the same opensuse's built service. I guess I have to wait some time for these installation issues to be solved before to install 2.6.0 and check the images that I get wrong if I try to edit them with Digikam's editor. Not many though. This app is great in so many ways. Thanks, and I will keep you informed, gps On 06/22/2012 04:53 AM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > --- Comment #35 from Gilles Caulier <caulier.gilles@gmail.com> --- > Official digiKam 2.6.0 release is out since few days now : > > http://www.digikam.org/drupal/node/656 > > Please, check if this entry still valid, or update report accordingly. > > Thanks in advance. > > Gilles Caulier >
Andreas, I think you need to help us with that a bit. We dont need any PreviewManager extension, we have an ExifData object in memory here and need to strip it. There's a bunch of makernotes which I'd simply remove. Some of them can be found in static const PreviewTags filteredPvTags[] in exif.cpp, some more seem to be in const LoaderExifDataJpeg::Param LoaderExifDataJpeg::param_[] in preview.cpp. We remove any trace of Exif.SubImage[1-4].* I'm unsure about the relevance of these (from preview.cpp): { "Exif.Image.JPEGInterchangeFormat", "Exif.Image.JPEGInterchangeFormatLength", 0 }, // 0 "Exif.SubThumb1.JPEGInterchangeFormatLength", 0 }, // 5 { "Exif.Image2.JPEGInterchangeFormat", "Exif.Image2.JPEGInterchangeFormatLength", 0 }, // 6 { "Exif.Image.StripOffsets", "Exif.Image.StripByteCounts", 0 }, // 7 { "Exif.OlympusCs.PreviewImageStart", "Exif.OlympusCs.PreviewImageLength", "Exif.MakerNote.Offset"} // 8 and { "Image", "Exif.Image.NewSubfileType", "1" }, // 0 { "Thumbnail", 0, 0 }, // 6 { "Image2", 0, 0 } // 7
Marcel, What's about patch proposed in this file by Varun ? Gilles Caulier
Andreas, Do you see the previous comment from Marcel ? Gilles Caulier
Varun, Can you update your patch against current git/master implementation ? Gilles Caulier
This is still unsolved, comment 30-33 and 37
Created attachment 88504 [details] attachment-21193-0.html hi Gilles, will check it out
Varun, Any news about this entry ? Gilles Caulier
digiKam 4.12.0 is out. https://www.digikam.org/node/741 Problem still reproducible ? Gilles Caulier
Bonjour Gilles, Je suis en DK 4.12.0 et le problème n'est plus reproductible (problem solved). merçi et à bientôt gps On 08/13/2015 05:01 AM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=298265 > > --- Comment #44 from Gilles Caulier <caulier.gilles@gmail.com> --- > digiKam 4.12.0 is out. > > https://www.digikam.org/node/741 > > Problem still reproducible ? > > Gilles Caulier >