On 06/12/18 02:38 AM, Joachim Durchholz wrote:
> Sorry for responsing late, it took me a while to get around to checking what
> came of the advice.
>
> Am 02.12.18 um 14:59 schrieb Anton Aylward:
>>> Q2: Is Darktable the right tool for the job?
>>
>> I would not think so.
>
> The thing that made me interested in DT is that it has a good image
> management GUI.
I can see how the central database over all images that were ever loaded can
appeal if it is heavily used for tagging and the like.That aspect is not in
my work-flow.
And perhaps I've had more experience, am more familiar with the other Linux file
management tools and their plugins, despite their comparative, being
non-centralized, other aspects.
> During my experiments with Hugin and IM I found that it is pretty hard to keep
> track of what image variant with what tool history is in what directory. It's
> also hard to get a quick overview over all the images in a directory.
that may simply be your unfamiliarity with the other Linux GUI file browsers.
I'll freely admit that the move from KDE3 to KDE4 'crippled' in the minds of
many users, aspects of tools such as the primary file browser. But there are
other file browsers. Yes, you may need a 'visualization, plug in for JPGs, you
specific RAW, for PDFs, for office documents. Yes, tat is documented, and yes
Linux documentation is not like Windows documentation.
And yes, those plugins let the file browsers scale up the images, but you always
have, even in DT, the issue that bigger preview images mean fewer of them
visible on the screen at once. And bigger screens, from the POV of a computer
user, become counter-productive once they get wider than your immediate field of
view. A 55-inch screen may be nice in the living room for viewing movies but at
computer operating distances it is too wide to take in atone.
IF AND ONLY IF you want more screen real estate I' do recommend a
one-screen-at-a-time approach. A 27-inch screen for viewing and side 17-inch
screen for controls is very nice to work with.
I can do that with GIMP. I'm just sad that DT doesn't have the ability to 'tear
off' the controls and move them to a side screen.
The other thing that newbies or Windows converts encounter with Linux is
overloading directories.
I grew up with hierarchical data models, call them 'taxonomies'. So for me the
Linux file tree model is quite natural. But many people try putting everything
into one flat directory/folder and wonder why the system is slow.
It need not be. Some Linux file systems don't handle large file systems well
and many tool try sorting file names by default, which is not nice when you have
hundreds or thousands of elements.
Yes there are file systems that don't have that problem, if you choose them when
installing Linux. Yes you can tell applications not to sort. But in general
the designers of the installation set the defaults for what they considered
'normal' operations, and what we are considering here is far from that.Not
everything scales well.
> I was thinking that DT might help me with that, apart from the image blend
> operation.
This is what I meant when I said
>> I think your mistake is in trying to define *single* a tool to do everything
That DT can do many things reasonably well does not mean that there are not
tools that do some of those things specifically well.
And what you are asking, even the basic operation, never mind the scale, is
non-trivial.
Whatever you end up with there is going to be a learning curve to surmount.
>>
>> I don't see why you dragged ImageMagick into this[1][2].
>
> I agree that it is too complicated to use.
> Worse, the detail behaviour of the individual operators can vary from version
> to
> version.
> Still, what's the alternative?
Unless I want to simply resize I NEVER use ImageMagick.
If I want to do anything non-trivial to an arbitrary JPG I'd probably use GIMP.
GIMP is also scriptable :-) I'm pretty sure that GIMP can do anything
ImageMagick can.
> Issue is that this means a lot of scripting, and coding, and it's taking
> months
> to get a suitable workflow rolling.
> (Shell scripting won't work, I have switched to Python...)
>
>> When you can demonstrate applying the 80/20 rule and have that 80% you will
>> be
>> feeling more confident and have a better feel for many of the details.
>
> It's roughly 400,000 pages, or 2,000 books. With 80/20 and just my free time,
> I'd be doing a book per day; you do the math how long it would take me to
> complete digitizing that.
Are these constraint imposed upon you? Can't you go back to your principals on
this and show them the scale of the issue?
I've read of other projects like this at universities where they get the
students to 'volunteer' for this kind of tedious but intellectually demanding
jobs in return for course credits.
>> I say this proportion basted on other projects in other fields of my life;
>> there
>> seems to be something in the nature of
