This is still missing in the master branch from OBS
@Chen_Hendrawan Reading this thread I realize that you might be feeling like you are talking to the wall. I just want to say that I really appreciate your opinions and different point of view. And we need these kind of discussions for the people who want to participate. The worst thing would be to lock ourselves into an echo chamber. With these discussions I’m sure nobody will get exactly what he/she wants but I’m also sure that we’ll come up with even better ideas together and eventually a better product.
While I agree with you, I find that most of the features that I requested got implemented (speaking as a non code contributor). It’s just a matter of actually using the software and taking the time to learn the current workflow before requesting features. When I really take the time to craft a feature request and explain all the benefits, speaking from the real world usage and back that up with edits from other software that show the benefits and end result that can’t currently be achieved in whatever FOSS software, I find that developers are willing to jump on it and contribute development time. That said, some things that I’d like are just not realistic right now and require a serious development time or some real funding.
Anyway, Darktable should clearly define to the potential users that DT is not a Lightroom replacement (at least for now). I think about Darktable more like about DaVinci Resolve or Blender. There is a learning curve to it but when you master it it can be a very powerful tool. Also user should be encouraged to read the manual, docs and engage in the communities…
Ok, I’ll make a new thread later to discuss a problem that I’ve just identified.
I don’t know what you mean by this. Don’t forget that the manual won’t be published until 3.4 is released so a lot of the links from the current master will not work until the release (because the last published manual is still 3.0)
Something eludes me here : why is forgetting about the sliders and controls you don’t know/understand, never an option ? Nobody said you had to use all the 72 modules darktable has, and change the default settings in each and every of them.
If we want to hide some less used parameters in a simplified UI, nobody will agree on what should be shown or not, because that depends a lot on your type of picture, condition of shooting and personal style. So it will end up as the usual “I am the average user and I know best” against the “no, I’m the average user and you are wrong”.
In all that mess, all I care about is enabling people with ways to achieve the look they want.
Everybody agrees that Photoshop is complex, because it targets painters, photographers, designers, webdesigners, videographers (yes, apparently, you can do video layouts in it), etc. and has to provide tools for each of them, while each of them perhaps uses 20% of the tools in it. The way I learned to use PS was starting with very basic tools, and then I expanded to others as the need arose, for specific pictures. You don’t learn PS linearly, with a 500 p. book, you google along your editing “how to mask hair” and that kind of thing.
So I don’t see how darktable is different. It has to serve for people editing raw photographs, scanned film negatives and positives, raster images coming from other softwares, and even camera JPG. Everybody should just focus on what is useful for them, and disregard anything they don’t need. The general rule of thumb is : if you don’t know what it is, you don’t need it.
The how is quite simple: download the code, make the improvements you think are worth to be done and then prepare a pull request to discuss the result.
Don’t expect others to do this for you - at least not the developers that are focussing on providing the best and most flexible tools …
Btw: they usually include ui improvements - but just those that doesn’t limit the flexibility of the tools
I don’t agree with this argument at all. And this comes up too often as an argument. You wouldn’t say to your 13yo kid to get a job and earn his own money to pay for learning a second language. You would listen to his proposal and if he wants to buy a new toy, you’d say no. But if he wants to join a language school you might find that very useful, consider that and pay for him to go.
This might be a terrible analogy but the point is, users should be guided not outright rejected. B/c most of them are not developers. And if a user crafts a great feature request that isn’t something terribly difficult, a developer might like it and develop it. Actually that’s how the current process works.
But users are not being guided. Now, nobody expect a dev to be a community manager and waste time on that. There should be a copy-paste template tho that a dev or anyone else could give to a user in this situations, not a reply like “Become a dev youself”. It’s like a world class editor/retoucher saying to the dev “become a great retoucher and get your own feedback”.
It works both ways. And there are probably ways to address this, we just don’t think it’s important as everybody is focused on their own thing and what they love the most and the occasional convos like this are easily dismissed.
Note the bolded part in the quote. That’s the key. Developers don’t find suggestions like “Simplify this interface” useful… What do you want them to do with it? Then, when the developers asked how they want it simplified, the reply often basically is “I don’t know” (or worse, like I’ve seen in another project: “That’s your job”…). Or the suggestion would require a complete rewrite of the internals…
Downloading the code and modifying it is the ideal case, but not at all evident: understanding a codebase of any realistic size is a non-trivial effort even if you have some notions of coding…
But unless I’m mistaken, the developers would look at a well formulated, specific suggestion, perhaps accompagnied by mockup of the proposed interface changes (“look at”, not “automatically implement” !), because that gives a solid base for discussion and further thought.
Can you provide an example or first draft of such a template?
Keep in mind that developers here are not paid, so they have to do this in their free time. Of course they prefer working on what they love most.
And the convos like this get dismissed because there’s not much to build on. In other projects I’ve seen the same thing: vague suggestions were rejected (ignored or more or less scornfully shot down), well-argumented specific suggestions did at least get a discussion, or a motivated rejection (something that looks realistic can in practice be impossible due to the implementation in place).
I completely agree, I’m just thinking about some community management. Not being an expert in that I can only do my best but it’s up to this community to put heads together and come up with some CM process and or materials.
Not right this second, but I’ve been thinking for a while about that and I’ll definitely write up something at least an initial document to get us started.
I am, I do not dismiss that at all. In fact I’ve been thinking about that too. That’s another thing we could work on a bit. But this is controversial as some of the devs don’t want to be payed. Like literally do not want to. But I’ve got some ideas beyond patreon and librepay (not ready to be shared atm, needs polishing (aka would fail probably)).
But there are questions still. How much would more money increase development? How much money are we talking about? How much are ppl committed, are they willing to leave their day job? Should we look to fund individual devs or a project as a whole so that the project distributes money. If second option, then how can a project accept payments and reward/pay devs while not being a foundation etc. I think there is some company or foundation that does that by acting as some sort of proxy without taking a cut.
A stupid question. Why the 18% grey in display reffered part is marked so close to the right part of the scale? Normally I would expect it on the left side of the scale and in case of a logaritimic scale even more to the left…
Because middle grey is always 2.44 EV below diffuse white. \log_2(0.1845) = -2.4383. 8 bits sRGB with its OETF can encode roughly 12.67 EV. So it makes sense that the middle grey is located at 81% towards the right.
What I would suggest and what would actually help is to make a nice onboarding screen. Like Blender, Darktable could have an onboarding screen where you could setup some default behaviors like setting up display or scene referred workflow by default. There could be a link to the documentation with suggestion of places to start reading. There could be an introductory message to read. Maybe “Tip of the day” (more like tip of the session) where we would show a useful tip to the user in a short one sentence. There is a lot more that could be done in onboarding. There shouldn’t be a link to this forum tho, we would be swamped by angry users who didn’t read the manual xD Ppl need time to adjust and accept that they don’t know anything about image editing.
Thank you. I wanted to make that suggestion but never had the time. Photoshop has something like that (the CC version). On pixls.us there’s already enough material (like this thread) to feed something like that. I don’t have PS at home but this should give an idea of what I’m talking about.
There’s also a lot of videos on youtube that could be linked and divided between getting to know the software, introducing RAW editing, workflows examples on darktable, etc. Luckily content is not missing.
Not darktable, but I think this thinking applies:I let the display transform handle both the gamut and tone transform to comply with whatever the display calibration program thinks the display requires. So, any tone transform I do in filmic or whatever is input to that transform. Both are cumulative to the final rendition on the screen.
For file export, I transform to sRGB gamut, sRGB tone and embed the sRGB profile. So how it gets displayed in the wild follows one of two paths:
color-managed, where the viewing software will use the embedded profile to transform to linear XYZ, and then to the tone and gamut of the destination display, or
not color-managed, where I’m imagining the viewer just sends the file’s pixels to the screen un-transformed, which has some prayer of looking okay on a sRGB-class screen. Bit of a wing-and-a-prayer, and I have little idea of what that looks like on non-managed HDR/wide-gamut…
Link to a readable sRGB tone transfer description:
That said, sRGB specifies a both a color gamut and tone transfer curve; one can build and use a profile that contains the gamut part but has a “unity” tone transform by specifying a gamma curve = 1.0.
