From my experience in engineering, the best documentation comes when the developer writes an initial technical document and then a technical author uses that to write a user facing manual. Knowing that it will be re-written takes a lot of the pressure off of the engineer/coder and having an experienced author ensures the user gets a great document at the end. Both working together ensures nothing is missed.
Yep, I've been hearing this argument a lot over the last week or so! Sounds like a solid argument too. Hopefully, the project can find another technical author who can assist Chris in his efforts.
As a software developer, and now senior IT leader with over 30 years of experience in the industry, I can tell you that one of the last things you want is a developer writing documentation. Writing code and writing documentation are 2 very different skills. Most devs (please note I said MOST) are not all that great at communication, written and otherwise. Let the devs do what they are good at, which is writing code, and let's recruit some more people to the project who are good at writing documentation. Hats off to Chris for the monumental task he has updating Darktable documentation. Good documentation takes time. I'm sure he'll get there. Kudos to the devs for writing what is arguably the best raw editor out there, bar none. And finally, thank you, Bruce, for the awesome videos. I've learned so, so, so much from you.
Michael, thank you for the kind words and the well-constructed reply. That's a very interesting take, and not one I'd considered (the whole "just because they can code, doesn't mean they can communicate"-angle!). And yes, good on Chris for taking it on, and doing it so well. But this does shine a light on various parts of the user manual which, in the past, have felt like they didn't really cover every angle of a feature or module. Now we know why. I wish I could devote the time to helping out, but I struggle to keep the production of videos up to the timeline I have in my mind!
@@audio2u Bruce, you are the one deserving of our thanks for all the great work you do. For the Darktable project, I have to imagine that there are Darktable users who are also highly competent writers as well. Just as the project attracts wonderful developers, we should raise awareness that we need some documentation writers, too. Then pair a writer with a dev or two so the dev can impart their knowledge to the writer of what the module does and how to use it. Once the writer is comfortable with the details, let the writer spin their magic. In my years of experience, this pattern has always yielded the best results.
Sounds perfect in principle. I guess it's the nature of FOSS that people aren't going to fall over themselves to offer their time/skill for no financial reward. :(
But HSL is not the default in other image editing apps; it's just one more option, so I'm not sure that that would solve the issue. Besides, for new sliders like we see in the colour equaliser module, we've got new functions which need defining.
About documentation; Let's be honest, everyone who writes code, does not like to write documentation. I know, it is wrong, but it is what it is! But Bruce is right! Don't forget that he is a great promoter and the go to guy, to learn the modules of Darktable!
Hahaha... don't try and make this about ME!! :) But yeah, I've been getting a lot of feedback this week about coders are not necessarily the right people to be writing the documentation, which was not an angle I had considered at the time I recorded this. But I can see that side of the argument. Some coders may NOT have the communication skills to effectively translate their scientific understanding of a new module/feature into a language that the common user might understand. That IS a fine art. Maybe I need to find out who wrote the code for the Colour Equalizer module and reach out to them for some one-on-one explanation.
FOSS is an interesting world to live in. I have to use Lightroom for some projects I work on, but I'm trying to set up darktable to replace it. I've always said darktable is like someone gave you a Ferrari for free, but you have to know how to install the tires, change the oil, adjust the suspension, etc... Thanks for all of your efforts!
That is a f***in' great analogy!! That is exactly what it's like! Keep digging. Believe me, it is so worth it in the long run. And thanks for the kind words.
@@audio2u I've also had to switch to Mac OS, unfortunately. There was some talk of dropping Mac support in the past. Do you have any info on the status of Mac support?
Bruce, thanks for this video and all your efforts. You provide an important supplement to the formal documentation. My supposition is that the best (maybe the intended) use of the enlarge canvas module would be to add width or height to shots with a very soft blurry background, like many macros or shots made with a wide-open telephoto with the subject at minimum focus distance and a distant background. I agree there are tools in GIMP and that other package that can handle such a job well.
Regarding the canvas enlargment module: Bruce, I remember what you did with the missing bit of sky after having Hugin produce a stitched pano. Hopefully, the same can now be done after correcting the perspective - without ever leaving darktable with all the drawbacks that come with it.
Aaaand… I was wrong or at least premature - what‘s left after applying perspective correction or rotation (with auto-cropping off) is still not accessible for retouching or liquifying :-( Funnily enough, if extra framing is added on top of perspective correction, the new bars work as advertised, leaving the black triangles intact :) I guess they just didn‘t think it through or maybe implementing the feature to work on those areas needed some untrivial code… Next release maybe?
Color Equalizer is really useful. For a while I've been doing quite a lot of black and white conversions and while I found various ways of doing them in darktable I always found the flexibility of controlling the brightness by colour to be limited. The new module makes it easy. I have a preset which simply reduces the saturation at all hues to base, then I use the dropper to select different colours and use the brightness tab to control whether each one goes up or down. It's as easy as that.
Hi Bruce thank you for this episode. You’re my goto-teacher for darktable. I have the following comment regarding your response time complaint in this episode. That slower reponse time is also related to your upgrade to the 4K display you’re talking about in episode 137. Under Windows I turn down the resolution of my 4K 15-inch display on my laptop (*) to 1080 points to have a decent response time on dt for some of my pictures. Just test the same picture on your 1080 points display. (*) 4K 15-inch display on a laptop: I agree that is over spec’d for a laptop, but I had no choice during the covid period because I had to buy something of-the-shelve when I wanted a powerful GPU)
The composite tool is something I've been waiting for. I occasionally do studio shots where multiple shots need to be composited. This applies especially to glass and shiny objects. I can edit the photos separately, export in tiff and do the compositing part in Affinity Photo, sure... but why? If darktable lets me do it, I can eliminate one tool from the chain. And darktable's output render will have all the EXIF data that Affinity happily mows down, so there's the EXIF copying step that I can also eliminate. Different people, different use cases, different needs, I guess.
Absolutely agree to your assessment regarding the issues with lacking documentation. I would not expect the programmers to provide all shiny formulated documentation, but on the other hand also would vote to only merge new functionality if at least a minimun amount of documentation about what the merged items actually do is available. Honestly, this would for me be a kind of "quality gate" that needs to be passed, before any new functionality can be merged finally to the to be release versions. As said, I would never expect to have a developer write high-end prduct documentation, but at least a sort of skeleton for the outer world to understand and potentially then explain their work in a final documentation for me would be mandatory in a project of this size.
The composite module is great, especially if you use the various masking options. I've had good results doing exposure blending and stacking multiple images with light trails, using multiple versions of the module
Interesting stuff. I just recorded 143 last night, and was experimenting with the composite module for just this purpose, following comments by Dean (Howarth?).
Enlarge is useful when you want to clone out distracting elements from the edge of the frame. Normally you can't 'get at' the edges easily, but if you enlarge the edge, do your retouch, then remove the enlarge, it's easy.
Shades of Douglas Adams 😂. I agree that the canvas extend has limited use. It's something that I regularly do with Gimp. I open the (exported) image, 'select all' then create a new document and extend its width & height by (say) 500 pixels. I then paste a copy of the original onto the new document. (It takes much longer to describe...). Using this method, I can make drop shadows, choose the canvas colour, hue, saturation brightness etc and end up with a pleasing social media presentation of my image. The dt module does not even have an eye dropper to select the colour. I also agree that the 3rd module too seems to deviate from the general historical theme of dt. Some would argue more is better. I would argue that (IMO frivolous) modules like these are less useful and not as polished as raster or pixel editing software incorporates and furthermore place an unnecessary burden on the code writers who write it and then maintain it. I suspect that they have been requested by users who perhaps don't appreciate the difference between a raw file editor and a raster image editor . Regarding the lag of documentation, I see no reason why the documentation can't be written as a first edition and then have addenda added as the software evolves. However, thanks for another excellent video, looking forward to part two, three... (four etc? 😂)
Well played, Bernie. Although, what was the Douglas Adams reference? Did I say something particularly Douglas-ish? Fun fact... I got his autograph while he was alive. He came into the ABC in Sydney while I was working there... would have been 2003-2004 at a guess. Don't recall when he died.
Hey Bruce. Great videos.... Thanks for guiding me toward your channel in the Darktable group on FB. 😎💪👍🤟🤘 if I need to get the photo into GIMP, I always save in PNG and then again in PNG when I export from Gimp.. Do you have any other recommedations to that process ?
Yeah, use TIFF rather than PNG. In any digital workflow (audio, video, photo), you should never use lossy codecs until you are ready to export a final version. Keep all intermediate assets in a lossless form.
In a large and complicated software collaboration, it is not a must for the developer to write the documentation. They might not be good at writing it or any reason. It is always better for someone else who specializes in writing documentation. It is not odd at all if you ever write code, especially open-source software, it is good to have someone else to take the writing burden off you. If you want, you can help write the documentation for the community. You only need to communicate with the developer to learn how to use the feature they write.
Yep, I've been getting this a lot over the last week! It was a concept that I had not considered... That the developer might not be the best person to write the documentation. As for contributing, I would love to, but I'm stretched for time already. I'm already struggling to produce the videos I want to get out. 😢
With you on the compositing stuff. It does need to be in one of the best RAW developers going. Would it not be simpler to make possible to export to any image manipulation programme in high res Tiff file format?
Love how the Color Equalizer is now Scene referred, HOWEVER: It's really lacking the feature to select by brightness or saturation, not just hue. The old Color Zones module had that option. Until that is updated i feel like the Color Equalizer is a step down sadly.
Hang on.... did you watch the video that I just released, or did you watch something else? The Colour Equalizer has 3 tabs... hue, brightness and saturation! Those tabs are for adjusting those qualities of your image. But you mention "SELECTING by those qualities". That's done by using a parametric mask, which is old news. :)
@@audio2u I did in fact watch the video. I'm not talking about the tabs. The 3 tabs are the values that are changable, you can change hue, sat or value PER Hue. Parametric masks are also sth different, they work in all tabs. If you go to the Color Zones module. underneath the curves there is a "select by" line. The default is select by "hue" and that works like the new Color Equalizer, however you can also do "select by Lightness" for example and do things like desat all the darks of an image.
@@audio2u Got no github account, but if you talk to the dev again feel free to forward the request. Either way, thanks for your work for the community!
Yes, the delayed documentation is an odd thing. I survive, but it has a negative impact on newcomers, who finally became convinced by the claims from us in the Darktable fan club - and as one of the first things find out that the latest part of the very essential documentation is missing.
When can we expect NIKON Z6III support if it is not in this version? Will that be in half a year? Can't it be sped up somehow? Thanks for your help with working in darktable.
I don't know what determines the time it takes for darktable to recognise new cameras. My suggestion would be to log a feature request on GitHub. Not that they need a feature request, but it might garner a response as to how long you night be waiting.
While I'm not sure I see myself using expand canvas and composite could they be used together to make a collage, such as adding a column to the left side of the image and then placing a couple of other images in that column? Personally I'd just use gimp for that but thats the only way I really see using expand canvas unless some sort of generative fill is coming in the future.
~ca. 4:00 I can honestly see both sides of this argument. But I for one would be very open towards it, but it would need to be its own thing, like the Lighttable, Darkroom functions. It could make Darktable a genuine one-stop shop. Or what Photoshop used to be before Lightroom. But letting this float around inside the Darkroom Module may, or May not be such a good thing. But, least we forget Potatoshop (lol) started out as a Digital Darkroom program. So idea isn't that whacky. Edit Typing on a Phone sux 🍑
@@audio2u Well I was thinking along the lines of a 1.. 2.. 3.. kind of Affaire 1 Image Management (Light Table) 2 Darkroom (Classic Darktable) 3 Actual Manipulation level (i.e. Classic Photoshop) The only thing from my perspective in 2024 is, is Photoshop even needed when everything we ever wanted Photoshop for, is achievable in either Lightroom or in this instance Darktable. e.g. Colour corrections. Perhaps the odd spot remover. But again. This is something that could in theory move to that third layer. Also I love GIMP. I could probably love it more post v3.0.2 but, I think Darktable has more Momentum to drive the changes it needs, given the shaper focus of it users. If we were honest about it we'd have to kinda admit that GIMP never knew what t wanted to be. As I recall it, it started out the same way Krita had, and we Photographers just kinda co-opted it, in the same way we're doing to Krita right now. At best it was a Temporary solution, which has since become the standard. I'm not going to say that GIMP is useless, it's far from. But to hold that up to Photoshop, in the way we hold Darktable up to Lightroom has always kinda rubbed me wrong. It has also clued me into why nobody outside our 'clique' actually seems to give a toss about CMYK, when 99.9999% of the Ink slingers out there while being CMYK, can't actually do anything with a CMYK File. But like myself everyone seems to want this more than life.
It never will be either. In darktable-land, any version number which ends with an odd number is a development version. Stable releases always end with an even number x.2, x.4, etc
I think the Enlarge canvas tool allows us to stay in Darktable without being forced to solve marginal pixel manipulation in GIMP, Affinity Photo 2, Photoshop, etc.
Which is exactly why I said "It's not MY thing". I am sure some people will use it and love it, and that's great. Whatever works for you, right? I will be the last person on Earth to say "do it my way or don't do it". :)
@@audio2u OK, I'm between systems ATM, so this is purely hypothetical, maybe even wishful thinking, but ... Let's say you've got a sunrise-seascape composition that you shot 2 bracketed exposures of, one dark one to protect the sky's highlights and one light one to raise the shoreline's shadow-detail. Up to now, the common practise has been to export the 2 separate processed images and blend them as layers in Gimp or some-such, using luminosity-masks. This module looks to me like it could do all of that within DT - process each exposure for it's desired qualities, then drop the lighter one onto the darker one, use difference blend-mode to aid alignment if necessary, then parametric-masking to allow only the sky onto the background-image of the shore. Does that sound realistic..?
@@deanhowarth2389 Can you not do that kind of thing already in darktable using LUA scripts? I have the script manager running and there is a "stack images" option that can do all kinds of things. There is also a HDR merge option.
Thanks for a great video. I do not agree with You that the software developers should write the documentation. It is an art of its own. Documentation writing is something that most developers hate and try to avoid. Translating what the developer made so that the user understands should be done by people with skills in that area. And as i have experienced myself is that when writing good documentation , there is often discussion with the developer and sometimes the software is changed to give better understandable software to the user.
Yeah, I've been shown the error of my ways since releasing this video! :) Seems yours is the more popular opinion. And I can understand that now that it's been laid out in clear and simply terms. I guess the dt project just needs some more people to step up and help out with translating the technical developer language into something the rest of us can understand.
Ok I'm as guilty of being a Dinosaur brain as the next old fart in the room. DLSRs > Mirrorless But, if these "Features" will ever get the proper management, say under a Compositions Tab, to go along with the current Lighttable, and Darkroom Tabs. I for One would probably welcome it.
@@audio2u I'm saying that I for One wouldn't be so fast to dismiss this 'Feature Creep' into Darktable. As long as this Feature Creep can be managed. Perhaps as a third phase behind the Lighttable & Darkroom Tabs. Which got me thinking that the (Digital) Darkroom is exactly where these tools should at least by definition should live. But, a jack of all trades is usually a master of none. How useful a canvases tool is in this context is? Is certainly questionable. But, I say let them continue. My "beef" is with AI, and as a helping tool. I'm more willing to embrace it. But that's NOT how AI is going, and while I'm never turning PRO, and, quitting the day Job. (As they say.) Id rather learn to git gud (get good), than BS the World into thinking that I am gud.
Bruce, with any new feature they should at least be able to give you all the info you need to make a video and there are some other people making videos as well. That last video you made for example should be the first thing any new user learns. I dread to think of the number of people who installed Darktable and then ditched it because they couldn't get the info they needed to actually use it. They need to stop with these unnecessary features complicating things and concentrate on getting new users. I can't even use Darktable now due to RAW files from Panasonic being not good at all for some reason, as I mentioned below, so no amount of new features is any good to me.
Under supported cameras on the Darktable site it says: DC-S1 (Panasonic) NO (WB presets) YES (Noise Profile) RAWSPEED But it's no good. Glitches and poor RAW processing that as far as I can tell goes way back. This highlights a general problem with Darktable. Things said to work but often don't work right or the way the say at all.
I've just tried Ansel which is Aurélien Pierre's version of Darktable. Already it's way better. He's slated the current version of Darktable and he's right. Darktable is dead now. This latest release proves that. Also I'm looking into loading Panasonic RAW with Libraw rather than Rawspeed in Ansel which you can do. Maybe you can take a look at Ansel Bruce?
The thing is you've got a bunch of independent developers who are each working on a feature or module which they feel the app needs. Two developers could be independently developing similar modules (see filmic RGB vs sigmoid).
@@audio2u I actually solved the whole issue I was having with the Panasonic imports. Rawspeed is actually working. It's to do with cropping of edges otherwise you get garbage around the edges but I can fix that in Ansel. As for Ansel. I'm looking through all aspects of that and reading Aurélien's rants and I have to say he is right. I know the way he behaves is a bit over the top but I can see his frustration. For example, the import in Ansel is simpler, superior and faster. That used to crash for me with Darktable. Ansel is way faster on my system. He's cut out so much nonsense bloat. Another example. What's that whole messy panel on the right for in the Lighttable? Stuff you will not always be using. It's all in menus now which is tidier. Often the older standard ways of doing things are tidier and more efficient. I just hope Ansel continues. What worries me is this disintegration into lots of apps and lack of cooperation but you still need a central figure to lead direction. It seems like Aurélien is a fanatical workoholic but that's good. He has a much clearer direction as far as I'm concerned. These new modules in Darktable indicate that the developers haven't taken note.
I thought about looking at Ansel, but... and you can accuse me of being self-serving here... I decided not to because I felt, rightly or wrongly (only time will tell), that darktable would have the larger audience, and therefore offer me the greater opportunity to build a substantial youtube channel on a product that doesn't yet have a massive following or a thousand other channels doing content for it. I should give Ansel a spin though, just to see what he's done.
If you don't provide at least the minimum amount of explanation how do people know how to use a new feature? The programmer might not be the right person to write it but someone needs to. In software development often the feature is not the programmer's idea. So the person who came up with the idea might be the right person, or someone else that is more teaching inclined. But someone should do it for the project to be adopted. I know we also need people that go in "blind" and start trying it and people that try to use it for things it wasn't thought of to find how it brakes outside the sequence of actions that it was built for and even to find what is the potential of the new feature but there are always people that ignore the explanation and use it. The common mortals need a minimal explanation to start working with it. Back in the day I would never have learned how to use Gimp if awesome people have never put out a Gimp book in pdf. Nowadays it's easier to make user documentation available online.
Totally get it, but I've been inundated over the last week with messages about this. There is just one guy, Chris, doing his best to write the documentation. So I feel for him, because that's no small feat!
I'm not sure how I feel about the inclusion of AI code into darktable. The more that kind of "assistance" finds its way into the app, the more we start to "dumb it down" for the non-technical user.
Ah ok... I'm not sure if that would be considered AI or more ML (machine learning). I'm not a coder, so I'm not sure, but I suspect the latter. I'm sure generative AI has its place in society. Yes, it's disruptive right now. That's true of most new technological advances. But I'm sure in time, it will help to create graphics and video that are simply too cost-prohibitive to do the analogue way. Hopefully, artists can find a way to co-exist with this new disrupter. Or maybe, AI-generated art will be the new middle-ground, and the human-generated content will be split down the middle. The REALLY good stuff will rise tot he top, and the mediocre stuff will sink without trace. Don't know. I guess time will tell.
The only AI feature I would like to see is 'AI masks' where you can ask the software to select the sky or a person. I posted a feature request for this but it hasn't been implemented yet but we will see what the future will bring
Darktable, or GIMP? 🤔 That's the question. If Darktable could pull it off great. But, I think this would put to question the use of Photoshop in a post Lightroom world.. When most Home Gamers, and their Dogs Rebel Ti Just want to play with RAW Colour correction Software, possibly in a Pro-amateur space. Also AI is a slippery slope. There are already some AI-esq functions in Darktable, according to one of Auréliens posted videos. But, Personally I feel that AI is toxic, and is something best avoided. Least we embrace Sodoku....
LOL, phrasing "X *must* happen" must be banned (pun intended) in conversations about FOSS. Newcomers take it as a serious entitlement and it does not help the quality of discourse at all.
@@audio2u, around 16:32, there is a conversation about introducing an additional time-gated requirement that "supporting documentation must be submitted by this date." It then discusses how FOSS is a personal hobby effort, which contradicts the segment's tone. Closer to the end, the video states that it was an odd decision to not have documentation for users on day one (btw, that is because users are not entitled and developers do not consider it part of their hobby), and closer to the beginning of the segment the wording is used "why is it not the job of the person who writes the feature..." (btw, that is because it is not their job, but hobby). IMHO, maintainers straddle a delicate balance between encouraging developers to contribute and have fun (it is supposed to be a hobby, right?... right?) and putting additional friction to do what they are not good at, documentation in this case. When a project gets a developer who plows through both, that is gold. It is rarely the case. I observed that only large projects attract more people who see their skills fit not for development but documentation because these projects give great exposure. I interview people and often hear them mention they had contributed docs to Python or code to a language with strict quality controls (and so well-documented). I do not remember a relatively small project like Darktable coming up in those scenarios.
Ahhh, gotcha! Yeah, since this video was released, I've had a lot of people chime in with similar comments re: developers not necessarily being the right people to write the documentation. And I can now see that side of the argument.
I used to use Darktable up to V3.6. Since then I do n to understand the continued additions/subtractions of modules, actions etc. I know there will be haters regarding my post but that's life. To me, Darktable seems to be a 'look what I can confuse you with'. After V3.6 I stopped using this programme. I used to like the way monochrome pictures could be made from a colour one but that module was changed and didn't work as it did before. As stated here Darktable is going down different avenues and I will not use it again UNLESS I could get V3.6 again..
From my experience in engineering, the best documentation comes when the developer writes an initial technical document and then a technical author uses that to write a user facing manual. Knowing that it will be re-written takes a lot of the pressure off of the engineer/coder and having an experienced author ensures the user gets a great document at the end. Both working together ensures nothing is missed.
Yep, I've been hearing this argument a lot over the last week or so! Sounds like a solid argument too.
Hopefully, the project can find another technical author who can assist Chris in his efforts.
As a software developer, and now senior IT leader with over 30 years of experience in the industry, I can tell you that one of the last things you want is a developer writing documentation. Writing code and writing documentation are 2 very different skills. Most devs (please note I said MOST) are not all that great at communication, written and otherwise. Let the devs do what they are good at, which is writing code, and let's recruit some more people to the project who are good at writing documentation. Hats off to Chris for the monumental task he has updating Darktable documentation. Good documentation takes time. I'm sure he'll get there. Kudos to the devs for writing what is arguably the best raw editor out there, bar none. And finally, thank you, Bruce, for the awesome videos. I've learned so, so, so much from you.
Michael, thank you for the kind words and the well-constructed reply.
That's a very interesting take, and not one I'd considered (the whole "just because they can code, doesn't mean they can communicate"-angle!).
And yes, good on Chris for taking it on, and doing it so well.
But this does shine a light on various parts of the user manual which, in the past, have felt like they didn't really cover every angle of a feature or module. Now we know why.
I wish I could devote the time to helping out, but I struggle to keep the production of videos up to the timeline I have in my mind!
@@audio2u Bruce, you are the one deserving of our thanks for all the great work you do. For the Darktable project, I have to imagine that there are Darktable users who are also highly competent writers as well. Just as the project attracts wonderful developers, we should raise awareness that we need some documentation writers, too. Then pair a writer with a dev or two so the dev can impart their knowledge to the writer of what the module does and how to use it. Once the writer is comfortable with the details, let the writer spin their magic. In my years of experience, this pattern has always yielded the best results.
Sounds perfect in principle. I guess it's the nature of FOSS that people aren't going to fall over themselves to offer their time/skill for no financial reward. :(
Perhaps by keeping the UI controls similar to what the rest of the industry uses (aka HSL) there wouldn't be a need for documentation.
But HSL is not the default in other image editing apps; it's just one more option, so I'm not sure that that would solve the issue. Besides, for new sliders like we see in the colour equaliser module, we've got new functions which need defining.
Hats off to Darktable team, and thank you Bruce for relaying the technical info. Cheers mate keep up the good work.
Thanks for the kind words.
About documentation; Let's be honest, everyone who writes code, does not like to write documentation. I know, it is wrong, but it is what it is! But Bruce is right! Don't forget that he is a great promoter and the go to guy, to learn the modules of Darktable!
Hahaha... don't try and make this about ME!! :) But yeah, I've been getting a lot of feedback this week about coders are not necessarily the right people to be writing the documentation, which was not an angle I had considered at the time I recorded this.
But I can see that side of the argument.
Some coders may NOT have the communication skills to effectively translate their scientific understanding of a new module/feature into a language that the common user might understand. That IS a fine art. Maybe I need to find out who wrote the code for the Colour Equalizer module and reach out to them for some one-on-one explanation.
So far the Color Equalizer looks like the most useful improvement for what I usually do. I really want to learn more about that.
I have opened a conversation with the developer in the hopes of learning more about the parameters in that module.
Great presentation, I can't wait to see part 2 & 3! Thank you for the time and efforts you put in to making Darktable easier to learn and use! Cheers!
No problem, glad it was helpful!
FOSS is an interesting world to live in. I have to use Lightroom for some projects I work on, but I'm trying to set up darktable to replace it. I've always said darktable is like someone gave you a Ferrari for free, but you have to know how to install the tires, change the oil, adjust the suspension, etc... Thanks for all of your efforts!
That is a f***in' great analogy!! That is exactly what it's like!
Keep digging. Believe me, it is so worth it in the long run.
And thanks for the kind words.
@@audio2u I've also had to switch to Mac OS, unfortunately. There was some talk of dropping Mac support in the past. Do you have any info on the status of Mac support?
Bruce, thanks for this video and all your efforts. You provide an important supplement to the formal documentation.
My supposition is that the best (maybe the intended) use of the enlarge canvas module would be to add width or height to shots with a very soft blurry background, like many macros or shots made with a wide-open telephoto with the subject at minimum focus distance and a distant background. I agree there are tools in GIMP and that other package that can handle such a job well.
Yeah, good point. Maybe it WOULD be easier to wrangle under those circumstances.
Another great example of this tool is for bird shots, modern cameras can focus edge to edge, it's not a dreadful AI replacement tool.
Regarding the canvas enlargment module: Bruce, I remember what you did with the missing bit of sky after having Hugin produce a stitched pano. Hopefully, the same can now be done after correcting the perspective - without ever leaving darktable with all the drawbacks that come with it.
Aaaand… I was wrong or at least premature - what‘s left after applying perspective correction or rotation (with auto-cropping off) is still not accessible for retouching or liquifying :-( Funnily enough, if extra framing is added on top of perspective correction, the new bars work as advertised, leaving the black triangles intact :) I guess they just didn‘t think it through or maybe implementing the feature to work on those areas needed some untrivial code… Next release maybe?
I would need to go back and watch the pano-stitching videos to fully recall what I was doing there.
Color Equalizer is really useful. For a while I've been doing quite a lot of black and white conversions and while I found various ways of doing them in darktable I always found the flexibility of controlling the brightness by colour to be limited. The new module makes it easy. I have a preset which simply reduces the saturation at all hues to base, then I use the dropper to select different colours and use the brightness tab to control whether each one goes up or down. It's as easy as that.
Yeah, nice. I shall have to experiment with that.
Hi Bruce thank you for this episode. You’re my goto-teacher for darktable.
I have the following comment regarding your response time complaint in this episode. That slower reponse time is also related to your upgrade to the 4K display you’re talking about in episode 137. Under Windows I turn down the resolution of my 4K 15-inch display on my laptop (*) to 1080 points to have a decent response time on dt for some of my pictures. Just test the same picture on your 1080 points display.
(*) 4K 15-inch display on a laptop: I agree that is over spec’d for a laptop, but I had no choice during the covid period because I had to buy something of-the-shelve when I wanted a powerful GPU)
Ahhh, interesting! I'll give that a go. And thanks for the kind words.
finally became a Patreon supporter. Thank for your great channel, Bruce!
Many thanks! I appreciate every single patron for their support.
The composite tool is something I've been waiting for. I occasionally do studio shots where multiple shots need to be composited. This applies especially to glass and shiny objects. I can edit the photos separately, export in tiff and do the compositing part in Affinity Photo, sure... but why? If darktable lets me do it, I can eliminate one tool from the chain. And darktable's output render will have all the EXIF data that Affinity happily mows down, so there's the EXIF copying step that I can also eliminate. Different people, different use cases, different needs, I guess.
Great points!
Absolutely agree to your assessment regarding the issues with lacking documentation. I would not expect the programmers to provide all shiny formulated documentation, but on the other hand also would vote to only merge new functionality if at least a minimun amount of documentation about what the merged items actually do is available. Honestly, this would for me be a kind of "quality gate" that needs to be passed, before any new functionality can be merged finally to the to be release versions.
As said, I would never expect to have a developer write high-end prduct documentation, but at least a sort of skeleton for the outer world to understand and potentially then explain their work in a final documentation for me would be mandatory in a project of this size.
Absolutely agree!
The composite module is great, especially if you use the various masking options. I've had good results doing exposure blending and stacking multiple images with light trails, using multiple versions of the module
Interesting stuff. I just recorded 143 last night, and was experimenting with the composite module for just this purpose, following comments by Dean (Howarth?).
As usual, great, thank you Bruce!
You are most welcome. Thanks.
Many Thanks for this new video, because yours are the best I know and best regards from Austria!
Ahh, Austria... You have kangaroos there, right? 🤣
Enlarge is useful when you want to clone out distracting elements from the edge of the frame. Normally you can't 'get at' the edges easily, but if you enlarge the edge, do your retouch, then remove the enlarge, it's easy.
Ahh, nice one.
Good one Bruce, thanks.
Thank you!
POTATOSHOP!! Good one :D
I used to be an Adobe ambassador and I heard another ambassador call it that! I thought it was hilarious.
Thanks!
No problem!
@@audio2u i learn darktable with you at the beginning. And I only say thanks
Shades of Douglas Adams 😂.
I agree that the canvas extend has limited use. It's something that I regularly do with Gimp. I open the (exported) image, 'select all' then create a new document and extend its width & height by (say) 500 pixels. I then paste a copy of the original onto the new document. (It takes much longer to describe...). Using this method, I can make drop shadows, choose the canvas colour, hue, saturation brightness etc and end up with a pleasing social media presentation of my image. The dt module does not even have an eye dropper to select the colour.
I also agree that the 3rd module too seems to deviate from the general historical theme of dt. Some would argue more is better. I would argue that (IMO frivolous) modules like these are less useful and not as polished as raster or pixel editing software incorporates and furthermore place an unnecessary burden on the code writers who write it and then maintain it. I suspect that they have been requested by users who perhaps don't appreciate the difference between a raw file editor and a raster image editor .
Regarding the lag of documentation, I see no reason why the documentation can't be written as a first edition and then have addenda added as the software evolves.
However, thanks for another excellent video, looking forward to part two, three... (four etc? 😂)
Well played, Bernie. Although, what was the Douglas Adams reference? Did I say something particularly Douglas-ish?
Fun fact... I got his autograph while he was alive. He came into the ABC in Sydney while I was working there... would have been 2003-2004 at a guess. Don't recall when he died.
@@audio2u The trilogy reference😂
Ahhh, of course! 😂
Just looked it up. Douglas died in 2001, so it was clearly before then!
@@audio2u Sadly died young. In the gym if memory serves.
Hey Bruce.
Great videos....
Thanks for guiding me toward your channel in the Darktable group on FB. 😎💪👍🤟🤘
if I need to get the photo into GIMP, I always save in PNG and then again in PNG when I export from Gimp..
Do you have any other recommedations to that process ?
Yeah, use TIFF rather than PNG. In any digital workflow (audio, video, photo), you should never use lossy codecs until you are ready to export a final version. Keep all intermediate assets in a lossless form.
@@audio2u Thanks alot... and again, great videos. 👍
thanks.
No worries!
In a large and complicated software collaboration, it is not a must for the developer to write the documentation. They might not be good at writing it or any reason. It is always better for someone else who specializes in writing documentation. It is not odd at all if you ever write code, especially open-source software, it is good to have someone else to take the writing burden off you. If you want, you can help write the documentation for the community. You only need to communicate with the developer to learn how to use the feature they write.
Yep, I've been getting this a lot over the last week!
It was a concept that I had not considered... That the developer might not be the best person to write the documentation.
As for contributing, I would love to, but I'm stretched for time already. I'm already struggling to produce the videos I want to get out. 😢
@@audio2u I understand 😀
With you on the compositing stuff. It does need to be in one of the best RAW developers going. Would it not be simpler to make possible to export to any image manipulation programme in high res Tiff file format?
You can already do that from darktable. It supports 16 bit TIFF export.
Love how the Color Equalizer is now Scene referred, HOWEVER: It's really lacking the feature to select by brightness or saturation, not just hue. The old Color Zones module had that option. Until that is updated i feel like the Color Equalizer is a step down sadly.
Hang on.... did you watch the video that I just released, or did you watch something else?
The Colour Equalizer has 3 tabs... hue, brightness and saturation! Those tabs are for adjusting those qualities of your image.
But you mention "SELECTING by those qualities". That's done by using a parametric mask, which is old news. :)
@@audio2u I did in fact watch the video. I'm not talking about the tabs. The 3 tabs are the values that are changable, you can change hue, sat or value PER Hue. Parametric masks are also sth different, they work in all tabs. If you go to the Color Zones module. underneath the curves there is a "select by" line. The default is select by "hue" and that works like the new Color Equalizer, however you can also do "select by Lightness" for example and do things like desat all the darks of an image.
Ahhh, right!
Wow, it's so long since I looked at Colour Zones, I'd forgotten about that!
Maybe log into github and start a Feature Request for that.
@@audio2u Got no github account, but if you talk to the dev again feel free to forward the request. Either way, thanks for your work for the community!
Yes, the delayed documentation is an odd thing. I survive, but it has a negative impact on newcomers, who finally became convinced by the claims from us in the Darktable fan club - and as one of the first things find out that the latest part of the very essential documentation is missing.
Yep. Exactly. It's not a good way to keep potential new users on board.
When can we expect NIKON Z6III support if it is not in this version? Will that be in half a year? Can't it be sped up somehow? Thanks for your help with working in darktable.
I don't know what determines the time it takes for darktable to recognise new cameras.
My suggestion would be to log a feature request on GitHub. Not that they need a feature request, but it might garner a response as to how long you night be waiting.
While I'm not sure I see myself using expand canvas and composite could they be used together to make a collage, such as adding a column to the left side of the image and then placing a couple of other images in that column? Personally I'd just use gimp for that but thats the only way I really see using expand canvas unless some sort of generative fill is coming in the future.
Yep, that sounds plausible. But like you, I'd rather go to gimp or affinity photo for that kind of job.
Hmmm, Darktable is trying to make this old dog learn new tricks, but with that could Composite be used to photo/focus stack images??
Someone else just mentioned that, here in the comments. I'm going to try that tonight when I get home.
hi, i was surprised with the new features, maybe AI will be part of DT in the future
Maybe, maybe not. One of the so-called "other features" is the REMOVAL of a piece of AI code in the Colour Calibration module.
~ca. 4:00 I can honestly see both sides of this argument. But I for one would be very open towards it, but it would need to be its own thing, like the Lighttable, Darkroom functions. It could make Darktable a genuine one-stop shop. Or what Photoshop used to be before Lightroom.
But letting this float around inside the Darkroom Module may, or May not be such a good thing. But, least we forget Potatoshop (lol) started out as a Digital Darkroom program. So idea isn't that whacky.
Edit Typing on a Phone sux 🍑
That's not a bad call... moving the Enlarge canvas feature to its own tab. Yeah, I think that has merit.
@@audio2u Well I was thinking along the lines of a 1.. 2.. 3.. kind of Affaire
1 Image Management (Light Table)
2 Darkroom (Classic Darktable)
3 Actual Manipulation level (i.e. Classic Photoshop)
The only thing from my perspective in 2024 is, is Photoshop even needed when everything we ever wanted Photoshop for, is achievable in either Lightroom or in this instance Darktable. e.g. Colour corrections. Perhaps the odd spot remover. But again. This is something that could in theory move to that third layer.
Also I love GIMP. I could probably love it more post v3.0.2 but, I think Darktable has more Momentum to drive the changes it needs, given the shaper focus of it users. If we were honest about it we'd have to kinda admit that GIMP never knew what t wanted to be. As I recall it, it started out the same way Krita had, and we Photographers just kinda co-opted it, in the same way we're doing to Krita right now. At best it was a Temporary solution, which has since become the standard. I'm not going to say that GIMP is useless, it's far from. But to hold that up to Photoshop, in the way we hold Darktable up to Lightroom has always kinda rubbed me wrong.
It has also clued me into why nobody outside our 'clique' actually seems to give a toss about CMYK, when 99.9999% of the Ink slingers out there while being CMYK, can't actually do anything with a CMYK File. But like myself everyone seems to want this more than life.
Good call re: Gimp v Photoshop is nowhere near the argument for darktable v Lightroom!
I noticed a documentation for a version 4.9, which is not out as I write
It never will be either.
In darktable-land, any version number which ends with an odd number is a development version.
Stable releases always end with an even number x.2, x.4, etc
I think the Enlarge canvas tool allows us to stay in Darktable without being forced to solve marginal pixel manipulation in GIMP, Affinity Photo 2, Photoshop, etc.
Which is exactly why I said "It's not MY thing". I am sure some people will use it and love it, and that's great. Whatever works for you, right? I will be the last person on Earth to say "do it my way or don't do it". :)
The release-notes don't mention it, but that composite module looks tailor-made for exposure-blending.
Oooh... please elaborate on that!
@@audio2u OK, I'm between systems ATM, so this is purely hypothetical, maybe even wishful thinking, but ...
Let's say you've got a sunrise-seascape composition that you shot 2 bracketed exposures of, one dark one to protect the sky's highlights and one light one to raise the shoreline's shadow-detail. Up to now, the common practise has been to export the 2 separate processed images and blend them as layers in Gimp or some-such, using luminosity-masks.
This module looks to me like it could do all of that within DT - process each exposure for it's desired qualities, then drop the lighter one onto the darker one, use difference blend-mode to aid alignment if necessary, then parametric-masking to allow only the sky onto the background-image of the shore.
Does that sound realistic..?
EDIT : I think that should've been "drop the darker one onto the lighter one"...
Ooh, that is awesome! I'd not considered that, but that sounds perfectly reasonable. I'll have to try that out and see how it works.
@@deanhowarth2389 Can you not do that kind of thing already in darktable using LUA scripts? I have the script manager running and there is a "stack images" option that can do all kinds of things. There is also a HDR merge option.
Thanks for a great video.
I do not agree with You that the software developers should write the documentation. It is an art of its own.
Documentation writing is something that most developers hate and try to avoid.
Translating what the developer made so that the user understands should be done by people with skills in that area.
And as i have experienced myself is that when writing good documentation , there is often discussion with the developer and sometimes the software is changed to give better understandable software to the user.
Yeah, I've been shown the error of my ways since releasing this video! :)
Seems yours is the more popular opinion.
And I can understand that now that it's been laid out in clear and simply terms.
I guess the dt project just needs some more people to step up and help out with translating the technical developer language into something the rest of us can understand.
I also question the usefulness of the enlarged canvas module. I feel that’s what Gimp or Photoshop is for.
Yup!
Ok I'm as guilty of being a Dinosaur brain as the next old fart in the room. DLSRs > Mirrorless
But, if these "Features" will ever get the proper management, say under a Compositions Tab, to go along with the current Lighttable, and Darkroom Tabs. I for One would probably welcome it.
Not quite sure I follow what you're saying here?
@@audio2u I'm saying that I for One wouldn't be so fast to dismiss this 'Feature Creep' into Darktable. As long as this Feature Creep can be managed. Perhaps as a third phase behind the Lighttable & Darkroom Tabs.
Which got me thinking that the (Digital) Darkroom is exactly where these tools should at least by definition should live.
But, a jack of all trades is usually a master of none. How useful a canvases tool is in this context is? Is certainly questionable. But, I say let them continue.
My "beef" is with AI, and as a helping tool. I'm more willing to embrace it. But that's NOT how AI is going, and while I'm never turning PRO, and, quitting the day Job. (As they say.) Id rather learn to git gud (get good), than BS the World into thinking that I am gud.
Gotcha.
Bruce, with any new feature they should at least be able to give you all the info you need to make a video and there are some other people making videos as well. That last video you made for example should be the first thing any new user learns. I dread to think of the number of people who installed Darktable and then ditched it because they couldn't get the info they needed to actually use it.
They need to stop with these unnecessary features complicating things and concentrate on getting new users. I can't even use Darktable now due to RAW files from Panasonic being not good at all for some reason, as I mentioned below, so no amount of new features is any good to me.
Under supported cameras on the Darktable site it says:
DC-S1 (Panasonic) NO (WB presets) YES (Noise Profile) RAWSPEED
But it's no good. Glitches and poor RAW processing that as far as I can tell goes way back. This highlights a general problem with Darktable. Things said to work but often don't work right or the way the say at all.
I've just tried Ansel which is Aurélien Pierre's version of Darktable. Already it's way better. He's slated the current version of Darktable and he's right. Darktable is dead now. This latest release proves that. Also I'm looking into loading Panasonic RAW with Libraw rather than Rawspeed in Ansel which you can do.
Maybe you can take a look at Ansel Bruce?
The thing is you've got a bunch of independent developers who are each working on a feature or module which they feel the app needs.
Two developers could be independently developing similar modules (see filmic RGB vs sigmoid).
@@audio2u I actually solved the whole issue I was having with the Panasonic imports. Rawspeed is actually working. It's to do with cropping of edges otherwise you get garbage around the edges but I can fix that in Ansel.
As for Ansel. I'm looking through all aspects of that and reading Aurélien's rants and I have to say he is right. I know the way he behaves is a bit over the top but I can see his frustration. For example, the import in Ansel is simpler, superior and faster. That used to crash for me with Darktable. Ansel is way faster on my system. He's cut out so much nonsense bloat. Another example. What's that whole messy panel on the right for in the Lighttable? Stuff you will not always be using. It's all in menus now which is tidier. Often the older standard ways of doing things are tidier and more efficient.
I just hope Ansel continues. What worries me is this disintegration into lots of apps and lack of cooperation but you still need a central figure to lead direction. It seems like Aurélien is a fanatical workoholic but that's good. He has a much clearer direction as far as I'm concerned. These new modules in Darktable indicate that the developers haven't taken note.
I thought about looking at Ansel, but... and you can accuse me of being self-serving here... I decided not to because I felt, rightly or wrongly (only time will tell), that darktable would have the larger audience, and therefore offer me the greater opportunity to build a substantial youtube channel on a product that doesn't yet have a massive following or a thousand other channels doing content for it.
I should give Ansel a spin though, just to see what he's done.
2:57 that only works in hue.
Yep.
@@audio2u but it's a shame, I miss a lot this feature in saturation and in brightness, hopefully it shall be introduced in a near future.
If you don't provide at least the minimum amount of explanation how do people know how to use a new feature? The programmer might not be the right person to write it but someone needs to. In software development often the feature is not the programmer's idea. So the person who came up with the idea might be the right person, or someone else that is more teaching inclined. But someone should do it for the project to be adopted. I know we also need people that go in "blind" and start trying it and people that try to use it for things it wasn't thought of to find how it brakes outside the sequence of actions that it was built for and even to find what is the potential of the new feature but there are always people that ignore the explanation and use it. The common mortals need a minimal explanation to start working with it. Back in the day I would never have learned how to use Gimp if awesome people have never put out a Gimp book in pdf. Nowadays it's easier to make user documentation available online.
Totally get it, but I've been inundated over the last week with messages about this.
There is just one guy, Chris, doing his best to write the documentation.
So I feel for him, because that's no small feat!
In enlarge canvas module is a good opportunity to implement some AI algorithm. Darktable needs that immediately.
I'm not sure how I feel about the inclusion of AI code into darktable.
The more that kind of "assistance" finds its way into the app, the more we start to "dumb it down" for the non-technical user.
@@audio2ufor me the only use of AI would be noise reduction. I don’t understand the popularity of generative AI.
Ah ok... I'm not sure if that would be considered AI or more ML (machine learning). I'm not a coder, so I'm not sure, but I suspect the latter.
I'm sure generative AI has its place in society. Yes, it's disruptive right now. That's true of most new technological advances. But I'm sure in time, it will help to create graphics and video that are simply too cost-prohibitive to do the analogue way. Hopefully, artists can find a way to co-exist with this new disrupter.
Or maybe, AI-generated art will be the new middle-ground, and the human-generated content will be split down the middle. The REALLY good stuff will rise tot he top, and the mediocre stuff will sink without trace. Don't know. I guess time will tell.
The only AI feature I would like to see is 'AI masks' where you can ask the software to select the sky or a person. I posted a feature request for this but it hasn't been implemented yet but we will see what the future will bring
Darktable, or GIMP? 🤔
That's the question. If Darktable could pull it off great. But, I think this would put to question the use of Photoshop in a post Lightroom world.. When most Home Gamers, and their Dogs Rebel Ti Just want to play with RAW Colour correction Software, possibly in a Pro-amateur space.
Also AI is a slippery slope. There are already some AI-esq functions in Darktable, according to one of Auréliens posted videos.
But, Personally I feel that AI is toxic, and is something best avoided. Least we embrace Sodoku....
LOL, phrasing "X *must* happen" must be banned (pun intended) in conversations about FOSS. Newcomers take it as a serious entitlement and it does not help the quality of discourse at all.
Remind me... what was this in reference to?
@@audio2u, around 16:32, there is a conversation about introducing an additional time-gated requirement that "supporting documentation must be submitted by this date."
It then discusses how FOSS is a personal hobby effort, which contradicts the segment's tone. Closer to the end, the video states that it was an odd decision to not have documentation for users on day one (btw, that is because users are not entitled and developers do not consider it part of their hobby), and closer to the beginning of the segment the wording is used "why is it not the job of the person who writes the feature..." (btw, that is because it is not their job, but hobby).
IMHO, maintainers straddle a delicate balance between encouraging developers to contribute and have fun (it is supposed to be a hobby, right?... right?) and putting additional friction to do what they are not good at, documentation in this case. When a project gets a developer who plows through both, that is gold. It is rarely the case. I observed that only large projects attract more people who see their skills fit not for development but documentation because these projects give great exposure. I interview people and often hear them mention they had contributed docs to Python or code to a language with strict quality controls (and so well-documented). I do not remember a relatively small project like Darktable coming up in those scenarios.
Ahhh, gotcha!
Yeah, since this video was released, I've had a lot of people chime in with similar comments re: developers not necessarily being the right people to write the documentation. And I can now see that side of the argument.
@@audio2u Yes, I also watched you talk about it in the other parts, cool of you to acknowledge, kudos.
I used to use Darktable up to V3.6. Since then I do n to understand the continued additions/subtractions of modules, actions etc. I know there will be haters regarding my post but that's life. To me, Darktable seems to be a 'look what I can confuse you with'.
After V3.6 I stopped using this programme. I used to like the way monochrome pictures could be made from a colour one but that module was changed and didn't work as it did before.
As stated here Darktable is going down different avenues and I will not use it again UNLESS I could get V3.6 again..
You could certainly compile from source and have any version you like.