Bug 298265

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
>