Here are some of my ideas on "idea to consider".
I have been shooting RAW exclusively for myself since 2005 and started using Capture One for processing.
But I do have older JPG and sometimes I do get JPG files from other sources (my kids for instance).
The question for me is not about processing JPG, but about Cataloguing images.
Darktable by default is set up to have everything online in some huge project.
I do not like that. It is unmanageable. And indeed it does not make sense to mix raw with JPG in such a setup.
I have since the early days used Capyture One's Sessions in my workflow. I think this is a really great concept.
You process a limited number of raw files and then archive them complete with processing information and database.
Very easy to archive, very easy to restore.
I am using darktable in a similar way. I have some shell scripts that create a 'darktable session', initiate a new database and process the images in this limited scope project.
This I can then archive. It does not work as smoothly as CO sessions, but it is usable as long as you strictly follow a set of conventions.
I generate JPG output files and move them into a JPG Catalog. That way I can treat darktable images, CO images and external JPGs all the same way and organise them in a logical manner.
There are a number of JPG catalog programs I tried, but none of them was "good enough" for me. So I created my own (Nodejs/Vuetify based) catalog, including metadata editor (Electron, still work in progress), but zero image editing.
All my images can be "online", which with RAW files would be much more difficult. (I do not print images).
So my idea is to not use darktable as a single monolithic repository.
Make it a bit easier to set up smaller independent 'darktable sessions'.
This would just require some interface tweaking, and does not impact any of the processing algorithms.
I would highly recommend that as a way of working.
Regards,
Jozef Dassen
Sent: Thursday, September 03, 2020 at 7:39 PM
From: a...@cybercord.com
To: "arūnas" , "darktable-dev@lists.darktable.org"
Subject: RE: [darktable-dev] idea to consider
All,
My first comment after following and using DT for 2 years. The question I have about the discussion about JPG, is why. Modifying JPG's in that format is fruitless. JPG is a 1 time use to send to some printers and vendors. Reworking JPG's we all know is a diminishing return function. It is a waste of time. Those that do not understand this should not be the developer's concern. I never shoot JPG. So why would I , the user of a high level program to make the original worse.
I've tried to explain this function to many amateurs and it goes no where. They do not understand RAW and just want to take pictures, not capture the art their eye sees.
Keep up the good work.
Regards,
Al F
Original Message
Subject: Re: [darktable-dev] idea to consider
From: Šarūnas <saru...@mailbox.org>
Date: Sun, August 30, 2020 9:06 pm
To: darktable-dev@lists.darktable.org
On 8/30/20 7:08 PM, Aurélien Pierre wrote:
> 1. that still doesn't give you the jpeg cooking recipe, which is more
> complicated than building an ad-hoc LUT or a tonecurve if local filters
> are applied (and there are),
>
> 2. what is it with people editing jpegs ? That's nonsensical ! Not the
> same workflow, not the same maths, not the same filters, not the same
> pipeline, not the same software. A raw is an output-agnostic linearly
> encoded master picture that you can still salvage from the beginning, a
> jpeg is already non-linearly cooked for display assuming dim viewing
> conditions (as per sRGB standard) and firmware blackboxes.
>
> People need to stop dealing with image processing as if everyone was
> right and correctness didn't matter. It's not a silly magic game of
> pixels values, there are assumptions to assert underneath the hood.
> Sometimes I wish image processing could kill people, as civil
> engineering or medicine do, so people would start taking it seriously
> and check the theory behind before doing shit carelessly. That kind of
> silly workflow will blow up in your face 50 % of times because there is
> zero reliability in handling pre-baked jpegs with all the firmwares
> discrepancies in a software designed to unroll image operations on raw
> files. Then I will let you deal with users who don't understand why the
> workflow is so unpredictable.
>
> Indulging bad habits of users is not a solution, especially since we
> don't sell anything/whore ourselves out. Let's be rigorous about pixels
> operations and do things properly. Want to edit jpegs ? Use bloody
> Photoshop and the likes. They are good at doing shit, don't care about
> color consistency, don't care about light emissions, don't even do
> associated a
