Re: RE: [darktable-dev] idea to consider
Le vendredi 04 septembre 2020 à 04:26 +0200, Jozef Dassen a écrit : > 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 think I do know darktable but the above sentence makes no sense to me. > 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. Perfect, that's exactly what darktable does. Import image, develop them and remove them. The .xmp left on the file system can be used to reimport the pictures. > 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. Seems like a huge mess for something already supported. I'll stop reading here as this message seems to spread quite a lot of wrong information. Please read the manual. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: RE: [darktable-dev] idea to consider
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
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 alpha occlusion properly. Yet people love them because > marketing expenses make up for dev mediocrity and overall stupidity. Amen. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
People who invest tens of thousands of dollars in high-quality cameras and lenses are served by a high-quality RAW converter that can convert to high-bit TIFF files. Darktable is such a converter. There is no compelling reason why we would focus our resources on .jpg conversion even if it were technically feasible. Per Inge Oestmoen, Norway > Chris Shelton wrote: Some photographers work in jpg only and sometimes I would not question their creative ability while maybe questioning the technical choice although I suppose they do avoid the mistake of overworking and gilding the lily I thought that the appeal of Darktable could be expanded to include people like this by having a facility whereby raw images are batch processed to create a set of jpg images in a similar way to the way jpg images are created by in-camera processing, maybe in the light table module; there would still be the option to work on a raw image as normal. I'm a bit overworked myself at the moment and struggle with RSI as you may deduce from the voice recognition I use . I did do C and C++ in the 90s though it would take a while to get up to speed; maybe one day ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
Hi, Am 30.08.20 um 14:22 schrieb Chris Shelton: Some photographers work in jpg only and sometimes I would not question their creative ability while maybe questioning the technical choice although I suppose they do avoid the mistake of overworking and gilding the lily jpeg is usually preferred when (non exhaustive list): * users do not want to invest time to lean how to process raw images. * user see no benefit of raw processing for their use-cases, i.e., they are just happy with out-of-cam jpegs. * time constrains do not allow raw processing (photo journalism). * customers require out-of-cam jpegs (photo journalism). I thought that the appeal of Darktable could be expanded to include people like this by having a facility whereby raw images are batch processed to create a set of jpg images in a similar way tothe way jpg images are created by in-camera processing, As Aurélien already explained this is not feasible for many reasons. It would require a tremendous investment in reverse engineering for each camera model, which usually comes with several picture profiles. It appears, however, that there is barely a real-world use case for such an out-of-cam jpeg emulation. Users, who really want the jpegs while still having the option to tune an image in a raw processor, shoot in raw+jpeg. Regards, Heiko -- -- Number Crunch Blog @ https://www.numbercrunch.de -- Cluster Computing @ https://www.clustercomputing.de -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
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 alpha occlusion properly. Yet people love them because > marketing expenses make up for dev mediocrity and overall stupidity. Amen. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · signature.asc Description: OpenPGP digital signature
Fwd: [darktable-dev] idea to consider
"Yet people love them because marketing expenses make up for dev mediocrity and overall stupidity." It's like VHS v Betacam or Windoze v Linux all over again! Cheers, Bruce Williams. -- Forwarded message - From: Aurélien Pierre Date: Mon, 31 Aug 2020, 09:09 Subject: Re: [darktable-dev] idea to consider To: 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 alpha occlusion properly. Yet people love them because marketing expenses make up for dev mediocrity and overall stupidity. Le 30/08/2020 à 17:05, Jason Polak a écrit : Another possibility is shooting Raw+JPEG. With this option you can still tune the JPEG engine in the camera somewhat with most models, and if you need to edit you can go to the Raw file. Also, you can make some minor edits directly on a JPEG file. Also, for people who are already working in JPEG, why would they suddenly switch to Raw format just to batch process Raw files to get what the camera would give them anyway? On 30/08/2020 08.22, Chris Shelton wrote: Some photographers work in jpg only and sometimes I would not question their creative ability while maybe questioning the technical choice although I suppose they do avoid the mistake of overworking and gilding the lily I thought that the appeal of Darktable could be expanded to include people like this by having a facility whereby raw images are batch processed to create set of jpg images in a similar way tothe way jpg images are created by in-camera processing, maybe in the light table module; there would still be the option to work on a raw image as normal. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
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 alpha occlusion properly. Yet people love them because marketing expenses make up for dev mediocrity and overall stupidity. Le 30/08/2020 à 17:05, Jason Polak a écrit : > Another possibility is shooting Raw+JPEG. With this option you can still > tune the JPEG engine in the camera somewhat with most models, and if you > need to edit you can go to the Raw file. Also, you can make some minor > edits directly on a JPEG file. Also, for people who are already working > in JPEG, why would they suddenly switch to Raw format just to batch > process Raw files to get what the camera would give them anyway? > > On 30/08/2020 08.22, Chris Shelton wrote: >> Some photographers work in jpg only and sometimes I would not question >> their creative ability while maybe questioning the technical choice >> although I suppose they do avoid the mistake of overworking and gilding >> the lily >> >> I thought that the appeal of Darktable could be expanded to include >> people like this by having a facility whereby raw images are batch >> processed to create set of jpg images in a similar way to the way >> jpg images are created by in-camera processing, maybe in the light >> table module; there would still be the option to work on a raw image as >> normal. > ___ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
Another possibility is shooting Raw+JPEG. With this option you can still tune the JPEG engine in the camera somewhat with most models, and if you need to edit you can go to the Raw file. Also, you can make some minor edits directly on a JPEG file. Also, for people who are already working in JPEG, why would they suddenly switch to Raw format just to batch process Raw files to get what the camera would give them anyway? On 30/08/2020 08.22, Chris Shelton wrote: > Some photographers work in jpg only and sometimes I would not question > their creative ability while maybe questioning the technical choice > although I suppose they do avoid the mistake of overworking and gilding > the lily > > I thought that the appeal of Darktable could be expanded to include > people like this by having a facility whereby raw images are batch > processed to create set of jpg images in a similar way to the way > jpg images are created by in-camera processing, maybe in the light > table module; there would still be the option to work on a raw image as > normal. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] idea to consider
Hi, Camera firmwares that convert raw to jpeg internally rely on proprietary and undisclosed algorithms. Emulating these is not merely a game of tuning input parameters, we need to reverse-engineer what algorithms they use, in what color space, and in which order they are applied, and repeat × pictures profiles × camera models × camera brands. Not to mention, manufacturers use their internal sensor knowledge to fine-tune algos, and we are in no position to compete by simple lack of access to this knowledge. darktable is already shipped with basic "basecurves" which emulate the overall tone/color intent of each brand using only its standard image profile, but they are limited, often inaccurate and no quality-control is performed on them. If people want to quickly get jpegs from their raws, any camera is provided with some proprietary piece of software that has much more educated guesses built-in than darktable, and knows about the camera firmware, such that you could get your camera jpeg back from your computer in no time. So I would say this : darktable is not a firmware emulator. We don't have the ressources to be, we already have an half-baked emulating method for what it's worth, and then what use would it be to mimic something that your camera already does better ? Designing a consistent raw workflow is enough work as it is, trying to take into account all the firmware discrepancies is simply madness in our context. Cheers, Aurélien. Le 30/08/2020 à 14:22, Chris Shelton a écrit : > > Some photographers work in jpg only and sometimes I would not > question their creative ability while maybe questioning the > technical choice although I suppose they do avoid the mistake of > overworking and gilding the lily > > I thought that the appeal of Darktable could be expanded to include > people like this by having a facility whereby raw images are batch > processed to create a set of jpg images in a similar way to the > way jpg images are created by in-camera processing, maybe in the > light table module; there would still be the option to work on a raw > image as normal. > > I'm a bit overworked myself at the moment and struggle with RSI as you > may deduce from the voice recognition I use . I did do C and C++ in > the 90s though it would take a while to get up to speed; maybe one day > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] idea to consider
Some photographers work in jpg only and sometimes I would not question their creative ability while maybe questioning the technical choice although I suppose they do avoid the mistake of overworking and gilding the lily I thought that the appeal of Darktable could be expanded to include people like this by having a facility whereby raw images are batch processed to create a set of jpg images in a similar way tothe way jpg images are created by in-camera processing, maybe in the light table module; there would still be the option to work on a raw image as normal. I'm a bit overworked myself at the moment and struggle with RSI as you may deduce from the voice recognition I use . I did do C and C++ in the 90s though it would take a while to get up to speed; maybe one day ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
