On 10/10/2012 11:35 AM, Mateusz Loskot wrote:
Hi!
> (Apology for long delay)
No problem at all I'm quite busy myself at the moment...
>>> 5. JPG versions are also imported to Shotwell, so I can
>>> filter collection and display developed versions (JPG
>>> only) to view, tag, upload to Flickr, etc.
>>
>>
>> Basically, if I got all you didn't mention anything here
>> that dt can't do. Metadata (IPTC metadata) is a weak
>> point of dt but if you're only thinking in free form
>> tags, why not do it in dt in the first place.
>>
>> Note the new grouping in dt which collects your JPG (or
>> whatever you have) to your RAWs in one display. Very
>> handy.
>
> Honestly, I'm used to the simple yet clear UI of Shotwell
> which suits the purpose of browsing, tagging and file
> management very well. DT is a fantastic software, but for
> photo files management it does not feel comfortable,
It works differently. If you live more in a db base view I
think dt does very well. But I agree one has to give up some
notions on file and folder for locical constructions like
collections (rolls) and keyword based selections. I admit,
that in principle I prefer the dt approach.
>> But I admit, I'd love to use dt as db as well, I just
>> miss some metadata. (Did I mention IPTC? ;)
>
> In my ignorance, I've assumed EXIF is roughly equivalent
> to IPTC metadata.
Well not really ;)
Headline, ObjectName, Abstract, Rating, ByLine & Name,
Location (Country, Code, Province, State, Sublocation),
Writer/Editor, Copyright, Source, EditStatus, Release
Date/Time, Expiration Date/Time, Credit, Contact, to just
name a few of the fields of IPTC besides the controled
vocabularies for image types is a bit larger than IPCT.
Probably, one could map it to XMP if one adds a bunch of
fields to the default Dublin Core of XMP. But Exif lives
more in the technical metadata domain, I think.
>> I'm not sure about shotwell but in mapivi I just use some
>> simple perl calls to copy a file back to darkroom and
>> call dt against it. (Basically, a minor second
>> disadvantage of dt: its not so easy to encance it with
>> simple stuff, as it lacks the ability to have some user
>> menue with simple calls that get selected files passed on
>> etc.)
>
> That would be handy for user-defined micro-plugins or
> macros, I guess.
Yes. Coding simple stuff in C(++) needs a lot more work than
in <place your favourite scripting language here>.
>> dt lives primarily on it's db. It reads in the xmps if it
>> can't find it, but its primary storage is it's db. One
>> might keep this in mind as this is a file based sqlite
>> storage. This could probably be an issue in large
>> collections. I've no idea where "large" starts and if it
>> is of any concern irl. However, there were some comments
>> about some other commercial product that gets into
>> difficulties with this kind of storage for large
>> collections and one is advised to split the db in smaller
>> junks. Given the above structure one could organize
>> R001-R099 in one db, R100-R199 in the next or something
>> the like if needs arrise.
>
> I need to figure out how to juggle the db files sensibly.
Well you can use a parameter on dt's invocation:
--library /path/to/your/dbfile
And given you use some simple (bash or whatever) startup
script one could think of something like
--library $HOME/DT/libraries/`basename $0`.db
storing all libraries labled by their top folder in some
fixed dir. Together with D&D of the folder to the DT startup
object, well, could work that way. Alternatively, some
simple perl or python-gtk with a simple selector. Or just
using not .db as extension but something like r001.dtdb and
associating dtdb with your darktable invocation object. Well
you get the idea. I think this is simpel.
> In the ancient times when I used Lightroom, I simply had
> separate catalogues for each film roll.
Hm, this effectively disables the database for searching as
you need to know where to find it already. So, I'd not use
something like that myself.
> I'd estimate number of photos per film roll between 500-1500,
> so I think, I could have separate library.db file per roll too:
>
> ~/Photo/R/R001/library.db
> ~/Photo/R/R002/library.db
>
> It may be difficult to figure out size of groups of rolls per library.db
> (R001-R099 or R001-R049 and R050-R099,etc)
> So, I'd rather simplify it and have library.db per roll.
>
> I hope, DT can happily work with such scheme, can't it?
--library on invocation is your firend here. For size
estimation a simple du -h $folder should do the trick. My
ingester uses some simple find function in perl.
>>> For example, if I tag photos in Shotwell, can I use these tags to
>>> search/filter files in darktable?
>>
>>
>> I'm not sure that dt will read the xmp in case it finds the film role in
>> it's internal db. So I can imagine that the other way round works smoother:
>> tag in dt and read in sw.
>
> I see, we can't ignore the fact library.db comes into play.
It is no real burden. With your folder based approach you
could even just delete it and let dt regenerate it every
time. Btw. its just an sqlite-file. So minimal <place your
favourite scripting language here> gives you even full
access.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
