How to purge labels from database?

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: How to purge labels from database?

Post by Mike Buckley » 06 Apr 16 21:31

It's impossible to accurately distinguish between the terms, import, download, and not import.That's because the Import module has two Import buttons, either of which is required to conduct the desired action even when the module, also titled the Import module, is configured explicitly "not" to import the files.

snowman1
Posts: 305
Joined: 01 Jan 07 3:13
Location: UK

Re: How to purge labels from database?

Post by snowman1 » 06 Apr 16 22:15

Frank, I understand now. More of a read-synch issue.

Mike, very true! To clarify I was using the word import to mean the action of importing into the catalog; the second section of the import module (the copy action being the first section, and where the renaming is applicable).* I really do like the way you can do either separately of the other.

*if you think that's bad, this afternoon I had to explain to a very confused person that a certain word meant one of three different things depending on the context it was being used in, all of which are quite likely to be used in the same sentence, and leading to a device being called by an apparently contradictory combination of names!
Snowman1
http://www.flickr.com/photos/snowman-1/
--------------------------------------

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: How to purge labels from database?

Post by vlad » 06 Apr 16 23:16

The importer module is indeed very powerful. The way I see it, it can actually trigger three different actions (scripting not withstanding):
(1) copying (and optionally renaming) the source images
(2) additional mirroring of source images (for backup purposes)
(3) image importing - applies to the image copies if (1) (and possibly (2)) was invoked, or to the source images otherwise

It is true that the source images can be copied and renamed without importing them to the catalog and, conversely, the source images can be imported without first copying (and renaming) them. However, I would note a limitation: the importer module does not support in one go the mirroring of source images (for backup purposes), followed by the subsequent importing of the source images. (Granted, such a scenario would not make sense if the so-called called "source images" are the originals on the camera card, but it makes sense (imho) if they are previously downloaded copies of the originals.)

Thus, I would prefer some additional flexibility, namely: being able to invoke copying or mirroring, followed by the importing of source images. Does that make sense to anyone else?

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: How to purge labels from database?

Post by Mike Buckley » 07 Apr 16 3:00

vlad wrote:the importer module does not support in one go the mirroring of source images (for backup purposes), followed by the subsequent importing of the source images.
Given your and my considerable understanding of the product, it's clear to me that I don't understand you. That's because I do exactly what I think you are saying can't be done beginning with Idimager Version 4, then Version 5, then Supreme Version 2 and then Version 3. Try running that by us again, please.

Not that this has anything to do with Stephen's intent of his thread. :mrgreen:

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: How to purge labels from database?

Post by vlad » 07 Apr 16 7:47

Sorry for not explaining it clearly, Mike. Is it possible to copy images from folder A to folder B (with or without renaming), then import the images from folder A? If yes, then how could I do this (in one go)?
Mike Buckley wrote:Not that this has anything to do with Stephen's intent of his thread. :mrgreen:
True, but I take comfort in Stephen writing about image importing himself, just a couple of posts ago :mrgreen:

tstoddard
Posts: 578
Joined: 07 Sep 12 12:51

Re: How to purge labels from database?

Post by tstoddard » 07 Apr 16 12:49

vlad wrote: However, I would note a limitation: the importer module does not support in one go the mirroring of source images (for backup purposes), followed by the subsequent importing of the source images. (Granted, such a scenario would not make sense if the so-called called "source images" are the originals on the camera card, but it makes sense (imho) if they are previously downloaded copies of the originals.)
vlad,

I think the limitation you are referring to is better described by saying: "the importer module does not support in one go the mirroring of source images (for backup purposes) without also copying them to a new folder." This limitation results in the situation where you can't make a backup copy into a different folder and import the original in one go. You can copy from folder A to folder B and mirror to folder C and then import from folder B in one go, but there is no way to just copy from folder A to folder B and import folder A.

I was aware of this limitation because it applies to my workflow. I use FastPictureViewer to rename and copy my originals from my camera card to my hard drive so when I import my files into my catalog in PSU I don't need to "copy them" or rename them. Because I'm not using the copy functionality in the import panel, I cannot use the "Apply mirroring" functionality. This isn't a big deal because I just make 2 copies of my files, one for importing and one for backup, using FastPictureViewer but it would have been more convenient to use PSU's mirroring.
Tom Stoddard

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: How to purge labels from database?

Post by Mike Buckley » 07 Apr 16 14:03

Ahhhhhhhhhh. Now that I see Vlad's clarification of what he would like to do in one go and Tom's post putting it in perspective, I have nothing to add other than to confirm that I agree that it can't be done.

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: How to purge labels from database?

Post by vlad » 07 Apr 16 21:17

Tom, thanks for your further explanations.

I would only like to add that the discussed limitation is by no means a showstopper or even a big deal (as I and others could adapt to it), but I expect that the implementation cost to remove that limitation would likely be low. The gained flexibility, translating into support for the described scenario, could justify that cost, imho.

Post Reply