The pixel pipe order is critical and should not be hidden. But for most users and most images the default order is fine. I can give an example of why I change the pixel pipe order. I use Filmic to get the basic look to my image, but then would like to tweak the contrast a little using curves. RGB curves are located before filmic in the pipeline. However, since I have just spent my time getting the image looking good in filmic and just want to do an additional tweak I want to place the RGB curves after filmic. Darktable lets me do this. Personally I cannot imagine why I ever want the RGB curves before filmic but the developers in their wisdom or oversight have placed the RGB curves before filmic. The beauty of darktable is the ability to rearrange the pipeline, but try to understand the difference between linear and non-linear processing steps if doing this.
On Thu, 18 Feb 2021 at 19:55, Andreas Herold <[email protected]> wrote: > > > Am 18.02.2021 um 06:20 schrieb Bill Wohler <[email protected]>: > > Andreas Herold <[email protected]> wrote: > > Am 17.02.2021 um 06:40 schrieb Bill Wohler <[email protected]>: > > How about a preference to sort the module lists by a) alphabetical b) > pixel pipe? I just wish the lists were alphabetical so that they would > appear in well-known places and be easier to find. > > I would say that a majority of the users love, love, love the developers > and the software, but don't care a hoot about the pixel pipe order and > wished it was done under the hood and not exposed in the UI (unless you > asked for it in the preferences). > > > Please don’t think, you would know what other users want. The order of > modules (create new instances, move them up and down) is a very basic and > great feature of darktable, that rises it wide above other tools. > > > Hi Andreas, are you talking about the display of the modules or the > pixel pipe order? > > > Hi Bill, > > the display of the module order IS the representation of the pixel pipe > order. If you think, you don’t have to care about the pixel pipe order, you > will run into problems. The same is true for other software with a fixed > pixel pipe order and you don’t know which order is used. I will try to > explain in which problems you are running. > > Let’s start with a very basic model, where a module is representing a > simple mathematical operation. > > Raw image Modules Final image > 1 -> [ + ] [ / ] [ ^ ] -> 4 > parameters: 3 2 2 > calculation: 1 +3 -> 4 /2 -> 2 ^2 -> 4 > > Now let’s use the same modules with identical parameters, but in different > order > > Raw image Modules Final image > 1 -> [ ^ ] [ + ] [ / ] -> 2 > parameters: 2 3 2 > calculation: 1 ^2 -> 1 +3 -> 4 /2 -> 2 > > You see, the order of modules (which IS the order of the pixel pipe) has > tremendous impact on the final image. > > Now let’s have a look on a very simple example covering two real DT > modules: „rgb levels“ and „color balance“ (assuming, that the RGB values > are not using the full range of values). > If „color balance“ is before „rgb levels“ in module order (= pixel pipe > order), than „rgb levels“, used with independent channels, will destroy > your already balanced colors. As a user, I always have to know what’s the > current order is, to avoid such mistakes. > > In my opinion, the user needs to have a model of the functionality in his > mind. The current discussion is in my opinion an indicator, that DT has > here some room for improvement. > > Best regards > Andreas > > > Chas G <[email protected]> wrote: > > I am wary of asking the devs to add another layer of complexity to the > interface. Every method of allowing > users to customize their interface adds: complexity, new points of > failure, another aspect new users will have > to learn, and more features that fewer people will care for. > > I hope the devs continue to do as they have: add underlying functions and > utility and keep it reasonably > simple. I believe they have done a remarkable job, and that their results > are proof that their intuitions are very > good. > > I hope they do not add layers of UI complexity. > > I should add that I am a long time but relatively unsophisticated > darktable user. Perhaps I am wrong in my > vision here. I would welcome any correction about my opinion from devs or > more sophisticated users who know > the interface programming that underlies the UI of darktable. > > But, why not allow the user to create a tab with aliases to the original > modules, which would > > never be altered whatever the alias tab displays ? > When the user needs to see what is really happening, he goes back to the > main tab, and when he wants to > work according to his taste, he uses his alias tab.>>>>> > > ____________________________________________________________________________ > darktable user mailing list to > unsubscribe send a mail to [email protected] > = > > ---------------------------------------------------- > Alternatives: > > ---------------------------------------------------- > > > -- > Bill Wohler <[email protected]> aka <[email protected]> > http://www.newt.com/wohler/, GnuPG ID:610BD9AD > > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to > [email protected] > > > -- > Bill Wohler <[email protected]> aka <[email protected]> > http://www.newt.com/wohler/, GnuPG ID:610BD9AD > > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to > [email protected] > > > > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > [email protected] > -- ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
