[KPhotoAlbum] Added a MoveOnCopy option to Categories.

[Miika Turkia]

Helo Andi,

I think you got me convinced. Now that I have played with the file version
detection it does seem to do the trick almost well enough. And it sure makes
more sense to have full control over all the files.

However, I could not figure out any way to show only the RAW files. Am I
missing something or is this not yet implemented? (This is needed whenever I
want to re-touch my images.)

Another feature that currently seems to be missing is "Annotate stack". This
would include the current image along with all the images in the same stack
for multi image annotation. (If only the initial annotation would be
perfect...)

miika

On Tue, Jul 5, 2011 at 11:46 PM, Andreas Neustifter <
andreas.neustifter at gmail.com> wrote:

> Hi Mikka!
>
>
> On 05.07.2011, at 05:52, Miika Turkia <miika.turkia at gmail.com> wrote:
>
> I have currently quite different approach for RAW work flow. I treat the
> RAW file as master and all the tagging is done on the raw. If a matching
> JPG, TIFF, or PNG exists they are skipped on the new image finder. However,
> image viewer shows e.g. the JPG  instead of decoding the RAW. The file with
> same name as the raw is the one that is treated this way, different versions
> and auto-stacking of them are not affected. This is something that I have
> just hacked together and have not committed nor am sure if I should commit
> at all.
>
>
> This approach (showing the JPG when clicking the RAW) is way to opaque for
> my taste. Also I want the option to have edit access to both (RAW & JPG)
> files from within KPA. So stacking those files (hiding them if necessary,
> showing them if needed) is the way to go for most users I guess.
>
> (Besides that, my next project is to create user-configurable editors for
> RAW and JPG files to have even more of a photographers workflow accessible
> from KPA.)
>
> The main reasons why I started to reconsider how RAW files should be
> treated were:
> - Having only one place for tagging of individual photo
>
>
> If tags are propagated during importing its only necessary to tag once.
>
> - Search queries would return only one item instead of many (even though
> stacks would help a lot here)
>
>
> I think stacks solve exactly that problem (always showing the "most
> viewable" image, providing access to the rest).
>
> Auto stacking might have been good enough but it lacks my main motivation
> for the (currently private) change, single place for tagging a photo. Does
> this kind of approach make any sense to others?
>
>
> See above :-)
>
> Thanks so much for sharing your workflow and your feedback,
>
> Andi
>
> On Mon, Jul 4, 2011 at 10:44 PM, Andreas Neustifter <<andreas.neustifter at gmail.com>
> andreas.neustifter at gmail.com> wrote:
>
>> Hi All!
>>
>> I use stacks in KPA solely for different versions of a picture (RAW,
>> JPG, edited JPG), those are automatically stacked as they are created.
>>
>> Also I use a category that tags the good and great images in a set
>> (selection tags), of course the tag gets moved from RAW to JPG to
>> edited JPG as the editing of the set progresses. (I guess that's a
>> pretty common work-flow.)
>>
>> Problem is that all the tags are copied from RAW to JPG to edited JPG
>> during auto stacking so more than one version of the image gets the
>> selection tag (which defeats its purpose).
>>
>> https://github.com/astifter/kphot
>> oalbum-fork/commit/2363b819e3894586570f9f038fab817bbd3fe9eb<https://github.com/astifter/kphotoalbum-fork/commit/2363b819e3894586570f9f038fab817bbd3fe9eb>
>> is a patch that adds an setting to each category that defines if tags
>> of this category are copied or moved during auto stacking (and
>> copying).
>>
>> I really do not know if this makes sense in any way so I would really
>> like your input on this, I tried it and for me it works.
>>
>> Thanks in advance for your feedback.
>>
>> Andi
>> _______________________________________________
>> KPhotoAlbum mailing list
>>  <KPhotoAlbum at mail.kdab.com>KPhotoAlbum at mail.kdab.com
>>  <http://mail.kdab.com/mailman/listinfo/kphotoalbum>
>> http://mail.kdab.com/mailman/listinfo/kphotoalbum
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20110710/cca61e29/attachment.htm>