[KPhotoAlbum] Original & modified images -> tell us how do you work with them?

Andreas Neustifter astifter at gmx.at
Sat Feb 13 12:20:29 GMT 2010


Hi!

On 13.02.2010, at 11:52, Risto H. Kurppa wrote:

> On Sat, Feb 13, 2010 at 11:50 AM, Andreas Neustifter  
> <astifter at gmx.at> wrote:
>
> Hi Andy, I appreciate your thoughts a lot, I feel this could lead to
> something new, keep it up :)

Trying to...

>> Maybe the second point of "Incoming" and the last two points of  
>> "Outgoing"
>> could be merged into a single consistent feature:
>>
>> *) Divide the external programs, that a file can be opened in, into  
>> two
>> categories: viewers (non editing) and editors.
>>
>> *) When an image is opened in a viewer, just open it.
>>
>> *) When an image is opened in an editor, make a copy (file.ext ->
>> file_1.ext) and open the copy in the editor.
>>
>> (The last two points would relieve the user of the decision if he  
>> wants to
>> edit, and thus use copy-open or if he just wants to view...)
>>
>> *) If the file differs after the editor is closed (does this mean  
>> the editor
>> would have to be a child of KPA?) keep the copy, stack it on top of  
>> the
>> original, copy tags. (Maybe copy EXIF data automagically?)
>>
>> *) If the file does not differ, delete the copy.
>
> Letting KPA delete files automatically makes me feel a bit  
> uncomfortable..

I was thinking of bytewise equal, so there is no real danger...

> But however, I think this breaks when working on RAW files:
> I have a RAW file, I open it (KPA creates a copy and opens it), export
> a .jpg or .tiff in the same dir - then what? KPA will delete the
> copied RAW file, leaving the raw recipe behind - but the next time it
> will not open the raw recipe (see ufraw for example). I'm not sure,
> this has to be thought throughly.

The RAW handling is a quite different area, thats right. State of the  
SVN is that a RAW file ancompanied by a JPG file on scanning new  
images is ignored by KPA, so KPA knows that a xxx.jpg is the developed  
version of a xxx.(raw|crw|cr2|...) file.

Unfortunatelly, when the JPG is created after the RAW was added to KPA  
the stack-and-copy-tags mechanism is not invoked. Thats a shame  
really, it would be great to have this not only for certainly named  
JPGs but also for JPGs that are named like RAW files.

To work the RAW handling into my proposal it would be necessary to  
mark any RAW-development software not as editor (which it really isn't  
since it does not touch the RAW file) but as viewer. Then the copy- 
open mechanism is not invoked. When KPA detects a new JPG that is the  
developed version of a RAW file it should stack those and copy the  
tags from the RAW  to the JPG. (I guess...)

I have never had a look at the file incoming/outgoing code, so I can't  
say how easy or hard this is to do...

Maybe I will have a look.

Cheers, Andi



More information about the Kphotoalbum mailing list