If I were to prioritize darktable for either image editing or digital
asset management, I'd choose image editing and manually place files in
locations where they make sense to me to be. It the developers could do
both, great, but keep the priority on image editing. One thing that
really irritates me about Lightroom is that Adobe pretty much dictates
how one should manage their own files. I'll choose my own structure and
process for digital asset management and to hell with Adobe.
Willy
--
"You don't take a picture. You ask quietly and humbly to borrow it."
- Unknown
--
On 6/26/20 4:43 PM, Robert Bridge wrote:
It comes up as a frequent topic. The thing about the file management
aspects is they are a small and relatively trivial subset of a far
bigger question: Digital Asset Management.
Currently darktable core has a basic DAM capability. Is it something
that can be improved? Yes. Is it something that even some of the core
devs might be interested in? I believe this is also yes.
However... (there is always a however!) there isn't a clear vision of
what the DAM needs: There isn't even an aspirational "user story", so
nothing at all in the design document area. My understanding is that
the big difficulty in significantly improving this aspect of darktable
is actually producing a solid specification and design.
All that said, I don't agree this is better handed off to
non-darktable tools, because ultimately a photographers toolbox should
deal with this critical part of the workflow.
Regards,
Robert.
On Fri, 26 Jun 2020 at 21:24, August Schwerdfeger
<[email protected] <mailto:[email protected]>> wrote:
The optimal solution, then, would be to allow those who want
file-manager capabilities to get and/or implement them without
having to distract the core developers from the image-editing side.
I think this would be best done through the Lua API. There are
already many file-manager-type operations fully supported through
Lua, and a few additions/improvements there would be more
beneficial than any amount of file-manager capabilities added in
the Darktable core, since it would enable people who are not so
familiar with C or the innermost guts of Darktable to make more
contributions, leaving the core developers free to tackle the
image editing.
--
August Schwerdfeger
[email protected] <mailto:[email protected]>
On Fri, Jun 26, 2020 at 2:29 PM Charlie Goodwin
<[email protected] <mailto:[email protected]>> wrote:
Seeing many posts asking for adding more and more file
management capabilities into Darktable, I'd like to suggest
that we do not divert attention away from the
greatest strength, image editing. I'd rather see the devs put
more attention into what makes Darktable a must-have, what it
can do so well with manipulating images.
____________________________________________________________________________
darktable user mailing list to unsubscribe send a mail to
[email protected]
<mailto:darktable-user%[email protected]>
____________________________________________________________________________
darktable user mailing list to unsubscribe send a mail to
[email protected]
<mailto:darktable-user%[email protected]>
____________________________________________________________________________
darktable user mailing list to unsubscribe send a mail to
[email protected]
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
