If you are using a file system based DAM you can also ignore darktable DAM
in the sense that you only will need to access the files by importing the
folders and then select them in the collect modules. But that does nothing
to do with XMP files, they store in them tags and ratings, but they also
store all the processing steps you have done to a file. Think about them as
a backup and safeguard of what you have in your darktable db in case it
gets corrupted. Also they are easier to backup than a library that can have
problems in it, unknown.
El lunes, 2 de diciembre de 2013, Chris Siebenmann escribió:
> | Le 02/12/2013 22:17, Jose Carlos Garcia Sogo a €crit :
> | > If you all are trying to shoot yourself on the foot and eventually
> | > loose all your processing to you different images is OK what you are
> | > proposing. Elsewhere you shoukd keep what darktable is proposing.
> |
> | I fully agree, I really find it strange to try hard to fight what
> | dt is offering and try to cripple it! dt has been designed to be
> | a all-in-one tool that can manipulate very large collection with
> | multiple way of selecting pictures from the whole set. Keeping only
> | the darkroom part seems quite a non sens to me :)
>
> Darktable is the best RAW developer on Linux today (in my opinion and
> I looked at all of the ones that I could find, including commercial
> options). If I had a choice between 'Darktable with DAM' and a program
> that was just as good without DAM, I would be using the latter because
> it is all that I need. But I don't. If I want the best RAW developer on
> Linux, well, it comes with a bunch of DAM features that I don't want and
> I get to work around them as best I can.
>
> I'd like to ask everyone to consider this use-case too. I think it
> speaks well for Darktable that it is the best RAW developer for Linux,
> not just 'a RAW developer with DAM'. But it does mean that there are
> people who are just going to be interested in the RAW developer side of
> it.
>
> (One of the many reasons that I'm not interested in Darktable's DAM is
> that I have already migrated from one RAW developer to Darktable. I have
> no particular guarantees that I won't be making a similar migration
> in the future and accordingly I very much don't want all of my asset
> management locked up inside a program that I may have to abandon in the
> future. Today I do asset management through the filesystem because I am
> pretty sure that anything will be able to deal with that, one way or
> another. In fact the RAW developer that I migrated away from had its own
> DAM, which I also didn't use. That turned out to be a really good thing
> in the end.)
>
> - cks
>
--
José Carlos García Sogo
jcs...@gmail.com
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Darktable-users mailing list
Darktable-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-users
