[Bug 286611] New: Tags are losts (randomly) when converting Tiff to Png

[philippe.quaglia]

https://bugs.kde.org/show_bug.cgi?id=286611

           Summary: Tags are losts (randomly) when converting Tiff to Png
           Product: digikam
           Version: 2.3.0
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Tags
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Created an attachment (id=65668)
 --> (http://bugs.kde.org/attachment.cgi?id=65668)
On this example, tagged tiff and png are shown. Note that the rated images have
their tag correctly transfered. However, in other try, it was not always the
case

Version:           2.3.0
OS:                Linux

When converting tagged Tiff image to Png with the "convert to png" tool
included in the batch queue manager, the new Png images sometimes have the
tags, sometimes does not, and even once get a tag previously removed from the
tiff image.

Reproducible: Always

Steps to Reproduce:
Send some tagged tiff images into the batch queue manager. Convert to png.
Compare the tags on the resulting png images.

Actual Results:  
Png images does not have the tags, or only some of them

Expected Results:  
Png images should have the same tags than the original tiff images.

See the attached screencapture.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Tags                        |Batch Queue Manager




--- Comment #1 from Gilles Caulier <caulier gilles gmail com>  2011-11-15 12:18:43 ---
This is strange because all code to move digiKam image properties from source
to target image exist in BQM :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/42a2f8c95c6f27f1d28bdef310d1f95aad635f27/entry/utilities/queuemanager/main/queuemgrwindow.cpp#L1111

Marcel, i see 2 possible issues here

1/ A race condition with DB registration of new item. Typically if database as
registered the new PNG file created by BQM, properties will be transfered, else
no. But ScanController::scanFileDirectlyCopyAttributes() is not able to wait
until item is registred to DB, or force item to be registered in all case ?

2/ A problem with metadatahub or another metadata management class, where a
confusion exist with, Rating, Labels, and Tags to transfert from orignal to
target image.

Philipe :

* do you tried some metadata rules when you converting.

1/ a TIFF image with rating as rating in PNG
2/ a TIFF image with rating+tags as rating+tags in PNG
3/ a TIFF image with rating+labels as rating+labels in PNG
4/ a TIFF image with tags+labels as tags+labels in PNG
5/ a TIFF image with rating+tags+labels as rating+tags+labels in PNG

Note : by "Labels", i want mean a color label or a Pick label that you can
assign to an image using Captions/Tags from right sidebar...

* Do you tried to convert TIFF to JPEG ? It's the same problem ?

* Do you tried to convert JPEG tagged images to TIFF or PNG ?  It's the same
problem ?

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[philippe.quaglia]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #2 from  <philippe quaglia laposte net>  2011-11-18 17:28:12 ---
Hello Gilles and Marcel
I have been doing some additionnal tests, and I attach also some
screenshots:

1/ a TIFF image with rating as rating in PNG
2/ a TIFF image with rating+tags as rating+tags in PNG

     See the firstscreenshot (RatedTifftoPNG): tags are not copied,
while the ratings are well copied.

3/ a TIFF image with rating+labels as rating+labels in PNG
4/ a TIFF image with tags+labels as tags+labels in PNG

     See the screeshot "tagsandlabels". Here, some labels are copied,
some not. Also, some tags are copied, while it is the same image and the
same configuration than in the previous example. Really strange !


5/ a TIFF image with rating+tags+labels as rating+tags+labels in PNG

And also TIFF -> JPG

     See the screenshot "FullTiffJpeg": still a big mess: no tags are
assigned to the Jpeg, while some png get there tags. The color label is
never transfered to the jpeg, while some png get it. The label is well
transfered to all the jpeg, and to some of the png, and the rating is
always transfered to both tiff and png.

Jpeg to Tiff

I have copied the previous JPEG to a new folder, and converted them back
to TIFF, as shown in the JpegtoTiff screenshot. As you can see,
strangely, for the picture "vanoise1998", there was no tags or color
label in the JPEG, but they appears back on the tiff during the
conversion. It's like if they are stored in the picture, but not
displayed properly by digikam, and they appear back after the second
conversion. Unfortunately, this is not the case for the other pictures.
Last try, with an other folder with "clean" jpg with tags, converting
them to Tiff once again results in a random assignation of the tags:
some are transfered, some are not.


I hope this helps.
Best regards.


Le 15/11/2011 13:18, Gilles Caulier a écrit :

> https://bugs.kde.org/show_bug.cgi?id=286611
>
>
> Gilles Caulier<[hidden email]>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Component|Tags                        |Batch Queue Manager
>
>
>
>
> --- Comment #1 from Gilles Caulier<caulier gilles gmail com>   2011-11-15 12:18:43 ---
> This is strange because all code to move digiKam image properties from source
> to target image exist in BQM :
>
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/42a2f8c95c6f27f1d28bdef310d1f95aad635f27/entry/utilities/queuemanager/main/queuemgrwindow.cpp#L1111
>
> Marcel, i see 2 possible issues here
>
> 1/ A race condition with DB registration of new item. Typically if database as
> registered the new PNG file created by BQM, properties will be transfered, else
> no. But ScanController::scanFileDirectlyCopyAttributes() is not able to wait
> until item is registred to DB, or force item to be registered in all case ?
>
> 2/ A problem with metadatahub or another metadata management class, where a
> confusion exist with, Rating, Labels, and Tags to transfert from orignal to
> target image.
>
> Philipe :
>
> * do you tried some metadata rules when you converting.
>
> 1/ a TIFF image with rating as rating in PNG
> 2/ a TIFF image with rating+tags as rating+tags in PNG
> 3/ a TIFF image with rating+labels as rating+labels in PNG
> 4/ a TIFF image with tags+labels as tags+labels in PNG
> 5/ a TIFF image with rating+tags+labels as rating+tags+labels in PNG
>
> Note : by "Labels", i want mean a color label or a Pick label that you can
> assign to an image using Captions/Tags from right sidebar...
>
> * Do you tried to convert TIFF to JPEG ? It's the same problem ?
>
> * Do you tried to convert JPEG tagged images to TIFF or PNG ?  It's the same
> problem ?
>
> Gilles Caulier
>

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #3 from Marcel Wiesweg <marcel wiesweg gmx de>  2012-02-20 20:57:32 ---
We should clean up a few issues, take some substantial changes introduced since
2.3 and then aim at a reevaluation of this bug once 2.6.0 is released.
(Phillippe, may you be able to test this again when 2.6.0 is released?)

Gilles: Is there a place in BQM where the temporary filename of the destination
file is generated? I would like to make the collection scanner ignore these
temp files.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #4 from Gilles Caulier <caulier gilles gmail com>  2012-02-20 21:59:15 ---
Marcel,

There are more than on e temporally files created when Batch Tool are applied
to an item.

A list of url host all of these here :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/queuemanager/manager/actionthread.cpp#L181

All temp files are created for each tool processed in loop. This list is used
at end to remove all of from hard-drive, excepted last one which is the target
file . In case of all is processed successively, this one is not deleted :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/queuemanager/manager/actionthread.cpp#L268

... and all others can be deleted as well here :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/queuemanager/manager/actionthread.cpp#L281

I hope that help you to ignore these files with collection scanner.

Gilles

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[philippe.quaglia]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #5 from  <philippe quaglia laposte net>  2012-02-21 18:11:57 ---
Hello Marcel,
No problem, I will perform some tests with 2.6.0 when available.
Best regards

Le 20/02/2012 21:57, Marcel Wiesweg a écrit :

> https://bugs.kde.org/show_bug.cgi?id=286611
>
>
>
>
>
> --- Comment #3 from Marcel Wiesweg<marcel wiesweg gmx de>   2012-02-20 20:57:32 ---
> We should clean up a few issues, take some substantial changes introduced since
> 2.3 and then aim at a reevaluation of this bug once 2.6.0 is released.
> (Phillippe, may you be able to test this again when 2.6.0 is released?)
>
> Gilles: Is there a place in BQM where the temporary filename of the destination
> file is generated? I would like to make the collection scanner ignore these
> temp files.
>

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #6 from Gilles Caulier <caulier gilles gmail com>  2012-02-21 18:41:17 ---
Philippe,

2.6.0 will be availlabe as stable only in a few months not before.

I recommend you to check with current git/master implementation.

http://www.digikam.org/drupal/download?q=download/GIT

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #7 from Marcel Wiesweg <marcel wiesweg gmx de>  2012-02-27 21:39:54 ---
Git commit bc72f7ae707dc0941f27ae26acf3b6e46af81751 by Marcel Wiesweg.
Committed on 27/02/2012 at 20:16.
Pushed by mwiesweg into branch 'master'.

Use temp file creation based on QTemporaryFile for BQM.
Use SafeTemporaryFile for JpegRotator.

M  +1    -4    libs/jpegutils/jpegutils.cpp
M  +13   -16   utilities/queuemanager/manager/batchtool.cpp

http://commits.kde.org/digikam/bc72f7ae707dc0941f27ae26acf3b6e46af81751

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Ananta Palani]

https://bugs.kde.org/show_bug.cgi?id=286611


Ananta Palani <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #8 from Ananta Palani <anantapalani gmail com>  2012-02-29 10:40:03 ---
(In reply to comment #3)
> We should clean up a few issues, take some substantial changes introduced since
> 2.3 and then aim at a reevaluation of this bug once 2.6.0 is released.
> (Phillippe, may you be able to test this again when 2.6.0 is released?)
>
> Gilles: Is there a place in BQM where the temporary filename of the destination
> file is generated? I would like to make the collection scanner ignore these
> temp files.

Could we do something similar with other temporary files? I've encountered
problems when tagging, especially when doing face tagging, where I apply a tag
and switch to another image. The old image gets renamed to a temp file, but the
new image is never created and digikam thinks the image is still there (i.e. it
is still listed in the album, but no longer on disk, except as the temp file).
I'm not sure this is caused by the collection scanner, but it seems to me all
temp files should be written outside the scope of the albums.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #9 from Gilles Caulier <caulier gilles gmail com>  2012-02-29 13:26:34 ---
Ananta,

Yes, i think Marcel plan do patch all Ktemporary file use in digiKam by the
same way. For ex, Camera Interface need to be patched like this...

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #10 from Marcel Wiesweg <marcel wiesweg gmx de>  2012-02-29 21:47:18 ---
Yet there is no temp file involved with face tagging or any other tagging,
asaik. Or does exiv2 use a temp file? I think it writes in-place.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #11 from Gilles Caulier <caulier gilles gmail com>  2012-02-29 22:00:17 ---
For tagging, there is no temp file. By I think Ananta said about temp file
created by ImageEditor :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/imageeditor/editor/editorwindow.cpp#L1984

I think this instance must be patched as in BQM.

About Exiv2, i'm not sure... I remember something about temp file created
somewhere by Exiv2 when image metadata are touch... Andreas can you confirm ?

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #12 from Gilles Caulier <caulier gilles gmail com>  2012-02-29 22:07:51 ---
Marcel,

Look in my Exiv2 PNG parser implementation. If i remember, to write metadata,
before to touch original, a temp file is created. We touch it in first, and if
all is fine, it will replace original at end...

http://dev.exiv2.org/projects/exiv2/repository/entry/trunk/src/pngimage.cpp#L228

Andreas can probably confirm that...

Gilles

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #13 from Marcel Wiesweg <marcel wiesweg gmx de>  2012-03-01 21:20:43 ---
Git commit 28a925833d5b9cd098960d27f7a05bba556d0b1e by Marcel Wiesweg.
Committed on 01/03/2012 at 22:19.
Pushed by mwiesweg into branch 'master'.

Use SafeTemporaryFile from EditorWindow

M  +18   -12   utilities/imageeditor/editor/editorwindow.cpp
M  +2    -2    utilities/imageeditor/editor/savingcontextcontainer.h

http://commits.kde.org/digikam/28a925833d5b9cd098960d27f7a05bba556d0b1e

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #14 from Andreas Huggel <ahuggel gmx net>  2012-03-02 01:02:03 ---
Yes, Exiv2 creates a temporary file when writing the metadata
(Image::writeMetadata) for images larger than 1MB. Then it removes the original
and renames the temp file to the original name.

-ahu.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Ananta Palani]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #15 from Ananta Palani <anantapalani gmail com>  2012-03-02 10:28:02 ---
(In reply to comment #14)
> Yes, Exiv2 creates a temporary file when writing the metadata
> (Image::writeMetadata) for images larger than 1MB. Then it removes the original
> and renames the temp file to the original name.

Would it be possible to inform Exiv2 where to put all temp files so that they
could be outside the scope of digiKam's collection scanner?

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=286611





--- Comment #16 from Gilles Caulier <caulier gilles gmail com>  2012-03-02 12:04:07 ---
As i know, as i developed some file parsers in Exiv2 in the past, i remember to
see temp file created where file to touch is located.

Perhaps in the future, it will be fine to be able to set where temp files must
be located by Exiv2.

I remember a bug report about this subject to set from KIPI host application a
common temp location for all kipi-plugins. This idea can be extented to whole
digiKam and shared Exiv2...

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=286611

--- Comment #17 from Andreas Huggel <[hidden email]> ---
Gilles is correct, the temp file is created in the directory where the original
image is. It is currently not possible to change that location. If that's a
desired feature, please open an issue for it in the Exiv2 Redmine at
dev.exiv2.org.

-ahu.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=286611

--- Comment #18 from Andreas Huggel <[hidden email]> ---
Gilles is correct, the temp file is created in the directory where the original
image is. It is currently not possible to change that location. If that's a
desired feature, please open an issue for it in the Exiv2 Redmine at
dev.exiv2.org.

-ahu.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Ananta Palani]

https://bugs.kde.org/show_bug.cgi?id=286611

--- Comment #19 from Ananta Palani <[hidden email]> ---
(In reply to comment #18)
> Gilles is correct, the temp file is created in the directory where the
> original image is. It is currently not possible to change that location. If
> that's a desired feature, please open an issue for it in the Exiv2 Redmine
> at dev.exiv2.org.
>
> -ahu.

I guess I should first determine if the temp file I am seeing is one created by
exiv2. Is the temp file simply the name image followed by a 4 digit number? So
for a file 'IMG_1679.jpg' the temp file might be 'IMG_1679.jpg4744' where 4744
is a number that randomly changes after each restart of digiKam

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel