Bug 129523 - editing images in other programs (e.g.: gimp)
Summary: editing images in other programs (e.g.: gimp)
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Interroperability (show other bugs)
Version: 0.9.0
Platform: unspecified Other
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-20 23:49 UTC by Dennis Gnad
Modified: 2019-08-09 10:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Gnad 2006-06-20 23:49:06 UTC
Version:           0.9.0-svn 2006-06-20 (using KDE 0.9.0-svn 2006-06-20)
Installed from:    KDE 3.5.3
OS:                Search

There should be a feature (after 0.9 release) to edit images in other programs than digikam, without loosing any of the important informations for the database, like date,exif,iptc,tags etc.
It could be part of somekind of versioning system (look at f-spot, bibble etc. - both can be tested free with f-spot even being open source, and both offer a versioning system for the images)
It could/should work like this:
-> when editing in another program not supporting the database stuff of digikam, it gets first copied to a temporary file
-> that temporary file is then opened in the other program (like gimp, or anything else)
-> digikam shows a question dialog "is the editing finished?" which offers "yes, copy it back" and "cancel"(which deletes the temporary file)
-> if "yes" is chosen, digikam will copy the image back with another name like DSC_xxxx_2.jpg (then maybe a new "version" of the image) and add the tags,date,exif,iptc informations which it should definately have, as it is valueable for the database
Comment 1 Heiner Lamprecht 2006-06-21 21:51:21 UTC
On Tuesday 20 June 2006 23:49, Dennis Gnad wrote:
>
> -> when editing in another program not supporting the database
> stuff of digikam, it gets first copied to a temporary file ->
> that temporary file is then opened in the other program (like
> gimp, or anything else)
> -> digikam shows a question dialog "is the editing finished?"
> which offers "yes, copy it back" and "cancel"(which deletes the
> temporary file)
> -> if "yes" is chosen, digikam will copy the image back with
> another name like DSC_xxxx_2.jpg (then maybe a new "version" of
> the image) and add the tags,date,exif,iptc informations which it
> should definately have, as it is valueable for the database


I think, versioning (in terms of "image X is derived from image Y") 
would be very fine.  But your workflow seems to be too difficult.  
It should be sufficient to be able to copy meta data from one image 
to an other, either in terms of only adding missing fields, or 
overwriting existing as well.


    Heiner
Comment 2 caulier.gilles 2006-06-21 22:03:00 UTC
Just a remark : a program like Gimp witch support like an hell metadata is a same for a photograph (:=)))

Gilles
Comment 3 Dennis Gnad 2006-06-21 22:18:58 UTC
> I think, versioning (in terms of "image X is derived from image Y") 
> would be very fine.  But your workflow seems to be too difficult.   
> It should be sufficient to be able to copy meta data from one image 
> to an other, either in terms of only adding missing fields, or 
> overwriting existing as well. 

Yeah to be able to copy metadata and stuff would be really helpful too. (and removing metadata, because on some cameras, if you use a manual lens, it saves wrong exif information (f1, 0mm etc.)

But I was talking about how other programs could be used on the images in digikam in a little bit easier way, so you don't have to separately copy the metadata by hand afterwards, and you can't forget to do it.

I anyway wasn't talking about how the versioning system could work, I don't exactly have a clue, but your idea seems really interesting, so you could have like a tree view that shows images, and new images which are made from the original? That sounds nice! Good idea!
Comment 4 Heiner Lamprecht 2006-06-21 22:33:49 UTC
On Wednesday 21 June 2006 22:18, Dennis Gnad wrote:
>
> But I was talking about how other programs could be used on the
> images in digikam in a little bit easier way, so you don't have
> to separately copy the metadata by hand afterwards, and you can't
> forget to do it.


Well, I fear, it would be difficult to monitor, wether the external 
program is still running.  And what happens, when you close digikam 
in the meanwhile?

> I anyway wasn't talking about how the versioning system could
> work, I don't exactly have a clue, but your idea seems really
> interesting, so you could have like a tree view that shows
> images, and new images which are made from the original? That
> sounds nice! Good idea!


Yes, something like this.  I don't know, how easy it would be, but I 
can imagine, that such a genealogy of images would be really cool.  
I often have different versions of an image.  The original file, a 
somehow enhanced image, an other one cropped and resized for the 
web, one printed, ...


    Heiner
Comment 5 Dennis Gnad 2006-06-22 15:38:13 UTC
> Well, I fear, it would be difficult to monitor, wether the external 
> program is still running.  And what happens, when you close digikam 
> in the meanwhile?

It doesn't has to be monitored if the external program is running or not. Digikam will offer you a dialog.
And, if digikam is closed, the image stays at it's place (somewhere in the homedir) and digikam will ask to import it again, at the next time it starts up, it then would have to save which picture was the original one it came from

> I often have different versions of an image.  The original file, a 
> somehow enhanced image, an other one cropped and resized for the 
> web, one printed, ... 

Yeah, me too! And sometimes even a subdirectory which has batch-process-scaled images..

--

Maybe all that stuff with external programs doesnt has to be done, when the picture can be added as a "sub-picture" of another, and then will maybe also get the same date,exif,etc. from the picture it belongs to?
Comment 6 Johannes Wienke 2009-10-22 01:48:28 UTC
Looks related to 115597
Comment 7 caulier.gilles 2010-07-29 10:43:51 UTC
*** Bug 245765 has been marked as a duplicate of this bug. ***
Comment 8 caulier.gilles 2011-11-24 09:12:22 UTC

*** This bug has been marked as a duplicate of bug 115597 ***
Comment 9 caulier.gilles 2019-08-09 10:58:05 UTC
Fixed with bug #115507