Bug 150801 - Thumbnail and image view does not update after editing image
Summary: Thumbnail and image view does not update after editing image
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Image (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-13 19:44 UTC by Geoff King
Modified: 2012-08-28 16:22 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.9.3
Sentry Crash Report:


Attachments
Retry saving metadata without IPTC if the first attempt fails (1.27 KB, patch)
2007-11-19 01:33 UTC, Paweł Marciniak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geoff King 2007-10-13 19:44:36 UTC
Version:           0.9.3-beta1 (using KDE 3.5.8, Kubuntu (gutsy) 4:3.5.8-0ubuntu1)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.22-14-rt

Thumbnail and main preview image does not update after editing image.  The only way I can see the actual image is in the editor.

Using SVN (0.9.3-beta1) as of Oct. 13, 2007 for both digikam and libs.  Also exiv2 v0.15

Example:
1 - take existing image (original.jpg) and edit, save as new image (new.jpg).
2 - exit editor and look at thumbnails.  

I see the original image thumbnail for both pictures.  
If left click to 'view' the new image, the original image is also shown. 
If I 'edit' the files, the new image is shown correctly.

I am aware of the option of rebuild all thumbnails, but on my system with many files this usually takes 10 minutes or more.  Plus as I am working I want to see the new thumbnail so that I can move the edited files to another directory easily.


Thanks,
Geoff
Comment 1 Geoff King 2007-10-14 04:41:15 UTC
Been messing around with this and have new info.  This looks to be related to the IPTC Preview tag that is added by the editor when editing and saving these scanned PNG files as PNG again.  Then when save the second generation PNG as JPG the preview tag is carried over into the subsequent JPG files. The PNG files are from xsane and were 16bit PNG. 

These tags were added and are part of the problem:

Iptc.Application2.Preview                    Undefined 30118  255 216 255 224 0 16 74 70 73 70 0 1 1 2 0 0 0 0 0 0 .....etc...

Iptc.Application2.PreviewFormat              Short       1  11
Iptc.Application2.PreviewVersion             Short       1  1

If i remove Iptc.Application2.Preview using the the following command the files are recognized, and digikam updates the thumbnails.
exiv2 -M"del Iptc.Application2.Preview" test1.jpg

In summary, the problem I am having appears to be due to the embedded Preview tags that are inserted into the PNG files in the editor when re-saving as a PNG file.  This only happens when using original PNG files. 

1 Create image using scanner as PNG
2 Use digikam editor on PNG file and save as PNG (preview tag is added)
3 Save as JPG file, preview tag is copied into jpg.
4 Digikam and Nautilus do not like these files with the IPTC Preview
5 Can then manually delete the Iptc.Application2.Preview tag to make things work again.

Let me know if you would like a test file.
Comment 2 caulier.gilles 2007-10-14 10:17:34 UTC
>1 Create image using scanner as PNG
>2 Use digikam editor on PNG file and save as PNG (preview tag is added)
>3 Save as JPG file, preview tag is copied into jpg.

==> normally it's impossible. the code disable IPTC preview tag to be stored in JPEG file. I'm sure, a bug report have been open in the past and i have fixed this one (0.9.0 release if i remember)

Why iptc preview is depreciate with JPEG. Because this iptc tag size can be set to 256Kb and a JPEG section is just limited to 64Kb. If you try to do it, JPEG file contents become invalid. Also, Exiv2 will not record preview iptc tag if content is too large to be stored in JPEG. In all case, digiKam witch use Exiv2 will never record preview in JPEG file...

Gilles
Comment 3 Paweł Marciniak 2007-11-19 00:56:46 UTC
Gilles,

You are right that the bug is fixed, in the sense that the JPEG metadata is not being corrupted. The problem is that when that happens, the whole metadata saving process is aborted, leaving the file without any metadata.

Ideally, only the IPTC preview should be skipped IMHO. But in order to do it, the exiv2 lib would have to be changed. Currently if the preview is too big, the Exiv2::JpegBase::doWriteMetadata() function throws an exception and doesn't continue.

I think nothing can be done here on the side of digiKam, because even at the lowest level, all metadata is written in one Exiv2 call (from KExiv2Iface::KExiv2::save()) and once that call throws, we end up with nothing.

Paweł
Comment 4 Paweł Marciniak 2007-11-19 01:33:57 UTC
Created attachment 22113 [details]
Retry saving metadata without IPTC if the first attempt fails

Attached is a patch to libkexiv2 that saves metadata without IPTC in case of a
throw from exiv2. It is not a real fix, so let it just stay here until exiv2 is
fixed, in case someone needs to save jpgs from pngs.
Comment 5 caulier.gilles 2007-11-19 13:53:44 UTC
Pawel,

Thanks to point me over this problem... but libkexiv2 is not the right place to fix it.

The bug is in editor... Look at this file:

http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/utilities/imageeditor/canvas/dimginterface.cpp?revision=709454&view=markup

.. over lines 598. 

Do you seen the bug... (:=))))

Gilles
Comment 6 caulier.gilles 2007-11-19 14:02:52 UTC
SVN commit 738683 by cgilles:

digiKam from KDE3 branch: force to remove IPTC preview tags from IPTC metadata if target file is JPEG.
CCBUGS: 150801


 M  +11 -1     dimginterface.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=738683
Comment 7 caulier.gilles 2007-11-19 14:06:43 UTC
SVN commit 738685 by cgilles:

backport commits #738683 from KDE3 branch
BUG: 150801


 M  +14 -6     dimginterface.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=738685