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

[Andreas Neustifter]

Hi!

On 12.02.2010, at 21:12, Risto H. Kurppa wrote:

> Looks to me that everyone (who have access to the code) come up with
> their own hack to match their workflow making KPA a bit of a mess with
> no real vision of what it is and should become.

I guess that's also one of the strengths of KPA, that it does not tie  
you to a certain workflow. I think this is good because everyone likes  
to use different tools for post processing/editing/touchups/RAW  
conversion/... KPA (in my humble opinion) adheres to the UNIX  
principle ("Do one thing and do it good") quite well as so far as its  
core strength is still fast tagging and fast retrieval of pictures

That said the UNIX-Philosophy is quite hard to translate to KPA  
because the Input/Output is not a simple text-stream (as with many  
UNIXy tools) but its a whole set of picture files. Additionally in  
every workflow there are pictures going out (because they are found)  
are manipulated outside _and then go in_ as "old but also new because  
edited"-pictures again. This is where the UNIX-I/O-Philosophy breaks  
down.

This area, getting pictures in and out and in again, is what is in  
great flux currently and I think that's great because the core of KPA  
(tagging and finding) is not too much affected by this. And it is  
important to have many ways of getting pictures in and out.

As far as I can see there is currently only one way how pictures come  
into the system, that is by having them in the KPA managed folder. I  
think its a good addition that there is a way to tell KPA that a  
picture is just another version of a picture by having a naming  
convention.
So there is:
*) copy to KPA folder
*) copy beside another (already managed) picture with a certain naming  
convention

As for going out, there are:
*) the KIM files (as general purpose export mechanism), great for  
scripts too. (BTW: I have a script to convert kim to plain text lists,  
anyone interessted?)
*) the HTML albums (pure export)
*) copy-paste
*) open in another program
*) copy-open in another program

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.

When making the naming convention for "edit-as-copy" and the one for  
detecting "same-but-different" images during import identical, would  
mean that one and the same mechanism can be used.

Okay, thats more than enough for now.

Andi