On vendredi 26 juin 2020 22:22:46 CEST August Schwerdfeger 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 don
On vendredi 26 juin 2020 23:43:21 CEST August Schwerdfeger wrote:
> As far as "user stories" go, I recall that users have written to this list
> more than once about two specific missing features: some form of batch
> renaming, and support for the full range of IPTC and other metadata, which
> is a
Just going to second what you said regarding the "fun" in darktable.
I've been using darktable for about five years now and have edited over
20K images. It is just really fun to use, which a lot of modules that
allow really fine-grained adjustment. The only thing I did not really
enjoy was noise r
I agree. There are already a multitude of ways to move, copy and bulk rename
files.
On June 26, 2020 7:27:53 PM UTC, Charlie Goodwin
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
Hi Tony,
I teach photography and imaging classes. I promote GIMP as a free
alternative to Photoshop because it does 99% of what photoshop does, is
free and in my opinion is nicer to work with. I do not promote DT as a LR
alternative because in my opinion it is not. LR is a program designed
With DT we are getting a great product for free because of the fantastic
effort of the developers. If someone wants to volunteer their time to
improve the data asset management side of DT then it would replace the need
of programs such as LR which is now a monthly subscription. If I had the
compute
Just my 2 cents. I also place the files myself in the 'right' directory
but it would be nice if there was no distinction between the import from
a camera and a 'normal' file system (a USB stick for example). At least
one should have the choice to copy them into the directory that they use
for D
As far as "user stories" go, I recall that users have written to this list
more than once about two specific missing features: some form of batch
renaming, and support for the full range of IPTC and other metadata, which
is a must-have for many professionals. Neither of these would preclude the
use
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 irrit
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 ev
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 f
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
On Fri, 26 Jun 2020 13:05:23 -0500
August Schwerdfeger wrote:
> Question: How difficult would it be to provide access through the
> Lua API to the naming patterns used for import-from-camera and
> export (e.g., a function that takes an image object and a pattern
> string and returns the correspon
Any Lightroom comparisons aside, having batch renaming somehow
integrated in Darktable (whether part of the import process or not)
would be very useful, for me at least.
Question: How difficult would it be to provide access through the Lua
API to the naming patterns used for import-from-camera and
"BTW, the OP is probably just a troll, he said to be moving from Lr but
Lr does exactly the same with the same naming IIRC (Import folder)."
Well, yes, I can agree with the first claim in this sentence *ONLY* if
you know me personally, have seen how much work I am investing in this
desire and
I now notice that when I search for a specific tag the results show
items that are not carrying the tag but are contained in a folder that
has a folder-name that includes the tag.
David
darktable user mailing list
to
On Fri, 26 Jun 2020 07:57:02 +0200
Pascal Obry wrote:
> Le jeudi 25 juin 2020 à 17:46 -0400, Robert Krawitz a écrit :
>
> BTW, the OP is probably just a troll, he said to be moving from Lr
> but Lr does exactly the same with the same naming IIRC (Import
> folder).
I'd like to make a correction a
* tony Hamilton [06-26-20 09:03]:
> This is an update after a few days of intense, all-day, reading and
> experimentation with the import function of DarkTable 3.0.2. What I am going
> to write here is at considerable length and will not be well received by the
> Darktable development team. It is
18 matches
Mail list logo
