Discussion about removal of some tools

[heckflosse]

I would like to discuss which tools will be removed for 6.0

Some that came to my mind using RT as a raw developer (using it for tiff/jpeg is a different story):

1) remove some demosaicers (AHD, EAHD, HPHD) 2) remove Edges 3) remove Microcontrast

To be continued...

[sguyader]

I can't pronounce myself for the demosaicing methods since I'm an xtrans user. Regarding points 2. and 3. I would vote to remove them, as I never use them. I've tried them in the past but never found them useful enough in my case.

[Thanatomanic]

I have to give this some more thought, in particular if we're really discussing removing features and breaking backwards compatibility.

I agree with @sguyader that edges and microcontrast could be removed without much loss of function. The same could be said about some of the color toning options.

[SilvioGrosso]

The more "duplicated" tools you remove, the easier is:

• to maintain the software in the long run;
• to keep the documentation updated;
• to facilitate the adoption for new users of RawTherapee (reading the forums it looks like they are often overwhelmed by having far too many options at hand...).

Therefore, + 1 to remove: 2. and 3 (edges and microcontrast)

Since, RawTherapee 6 version will be a major release I think you can safely break "backward compatibility". As usual, nobody is forced to upgrade :-)

If I recall correctly, a major gripe of Alberto Griggio, the creator of ART [1], was the redundancy of too many "similar" tools.

[1] https://discuss.pixls.us/t/art-the-software-news/14334

[Hombre57]

I remember that decisions were collectively taken to add several ways of doing things (e.g. in color toning) because user A prefer method A over user B preferring method B. Looks like lots of things has changed since few months. I don't really care to annihilate some stuff that I've spent lots of time on, but I hope I won't be the only one to accept that.

It would also be sad to suppress a tool because the GUI is suboptimal (not compact enough).

@heckflosse Regarding micro-contrast, haven't you told me that it was interesting for PixelShift images ? Or is there a better option now ?

If I recall correctly, a major gripe of Alberto Griggio, the creator of ART [1], was the redundancy of too many "similar" tools.

I can hear that, but then you should find a new meaning for Therapee. Also since @agriggio has already started that simplification work in his fork, is there a reason to run behind him in the same direction (duplicated work) ? Just asking to avoid wasted time again.

[heckflosse]

@Hombre57

Regarding micro-contrast, haven't you told me that it was interesting for PixelShift images ? Or is there a better option now ?

With Capture sharpening I see no need for Microcontrast tool (at least for raw files).

[sguyader]

I think @Hombre57 made a point, and I was already thinking the same: Alberto's fork (ART) took a drastic step in simplification, and maybe both RT and ART can leave side by side, fulfilling slightly different needs.

[heckflosse]

@sguyader

Alberto's fork (ART) took a drastic step in simplification, and maybe both RT and ART can leave side by side, fulfilling slightly different needs.

But why should RT not be simplified as well? Maintaining stuff which noone uses needs a lot of dev (support) time which could be spend better...

[SilvioGrosso]

Hello @Hombre57

Please, do not get me wrong: I DO appreciate your present and past work on RawTherapee. Especially because you did it on your very limited spare time, for free! For instance, I am really looking forward to having included in RawTherapee, sooner or later, depending on your time to work on it, the "Spot-removal-branch" [1]. This is a feature which has been requested oftentimes in the past :-)

I am persuaded that RawTherapee and ART can be excellent companions, for everyone's joy. There is no need to duplicate the efforts... For example, as regards the local editing tools, I am glad Desmis has been following a different approach with his branch [2], compared to Alberto Griggio's software.

I am also aware RawTherapee could have a better GUIs but this takes a lot of time and unfortunately I am not a developer or a CSS wizard and I can't give any help on this... This topic has been discussed quite a lot in the past. E.g: https://discuss.pixls.us/t/can-we-make-rawtherapee-look-less-complex-on-very-first-sight-for-brand-new-users/14105

[1] https://github.com/Beep6581/RawTherapee/commit/c23f9763023d7eab127968e1e8e9ff2dea5edc4d [2] https://github.com/Beep6581/RawTherapee/tree/newlocallab

[Hombre57]

@sguyader I'm not saying that both should be maintained.

My 2 questions was rather :

1. is ART oversimplified already or can this be a new starting point ?
2. will users agree on the tools we (i.e. ~5 guys) chose to remove ?

@heckflosse I don't mind removing the 3 tools you proposed, if they're useless or inefficient.

If you want my contribution to the list, I'd remove the whole Batch Editor panel. You'd still be able to edit multiple files through partial copy/pasta (which granularity could be finer if really necessary), and that would be enough for me. You won't be able to local edit your file with this mechanism anyway, it's just too complex to implement. Removing that to make local editing happen sooner would be a good trade-off (and hopefully it will be simpler to backport ART's feature).

[heckflosse]

@Hombre57

I'd remove the whole Batch Editor panel

:+1:

[sguyader]

I'm not saying that RT shouldn't be simplified at all. Just that I can understand if some tools remain, even if they are not widely used. Regarding the batch editing panel, in fact that's something that I miss sometimes in ART, as it is quicker to set some parameters to a bunch of files than using partial copy/paste. But I can live without it (and I do with ART).

[Floessie]

@SilvioGrosso

Since, RawTherapee 6 version will be a major release I think you can safely break "backward compatibility". As usual, nobody is forced to upgrade :-)

The last sentence doesn't reflect reality: Of course will users be forced to upgrade as distros switch to 6.x. And even if John Doe is able to build an older 5.x now it will bitrot until it's no longer compilable on then modern distros.

There is no such thing as "safely breaking backward compatibility", IHMO.

[Hombre57]

@Hombre57

I'd remove the whole Batch Editor panel

+1

It'd be probably better to drop a line on Pixls.us before suppressing such a feature, IMHO.

[Beep6581]

since @agriggio has already started that simplification work in his fork, is there a reason to run behind him in the same direction (duplicated work) ?

My sentiments exactly.

[Hombre57]

\

@SilvioGrosso

For instance, I am really looking forward to having included in RawTherapee, sooner or later, depending on your time to work on it, the "Spot-removal-branch"

I'm very busy in my job, free time is scarce and I don't want to spend everything on RT. Yet I have marged dev into spot-removal branch and will try to find the time this w.e. to add the final touch. But keep in mind it's only a clone tool for the moment (but I still find it useful).

\

[Krijger]

@sguyader

Alberto's fork (ART) took a drastic step in simplification, and maybe both RT and ART can leave side by side, fulfilling slightly different needs.

But why should RT not be simplified as well? Maintaining stuff which noone uses needs a lot of dev (support) time which could be spend better...

Just want to inspire you all to make the best software you can think of trusting your own product vision, while using any fork (and community feedback for that matter) as inspiration as well. There is no need to not do something because a fork already does it - also because you should not make assumptions about the life expectancy of a fork, nor should users be expected to change tools all the time.

@community, for the development of RT, ART is a side note, like "by the way, ART chose to do this in a certain way, which may be a good idea here as well", but not to constantly compare or to create a sense of competition.

In short, on

There is no need to duplicate the efforts...

I strongly disagree, as long as the efforts are in line with the vision of the maintainers, [EDIT after reading @Hombre57 "avoid wasting time" comment]... and where possible also taking into account efforts of contributors

[TechXavAL]

I don't wish to interfere in this discussion: a plain user here. I came here by chance, and maybe I have something to say.

You're discussing about removing tools because they are seldom used, or not used at all. I agree, but I would frown at a decission taken without asking the users, those that you try to please.

In my case I am a Microcontrast tool user, and if I don't use it more often it's just because it's not included in the Post-resize sharpening tool. You say it's currently only useful with non-raw files (because we already have Capture Sharpening), but if you remove it, then RT will automatically have less appeal to me (or others), because to give an extra crispness to a final/exported image, I would have to open it in Gimp, while I could just open it in my beloved RT and 2 clicks away I would have my image.

Microcontrast is just an example. There may be other tools with the same problem.

Why not working in the UI, putting together similar tools, perhaps with a combobox to select which one to use? If they do mostly the same, then a knowledgable user should know which one to use and how to choose it. If it's a newbie, then give that user a default tool (probably the most current one). If that newbie wants to learn, then point him to Rawpedia.

About «backward compatibility» I've always thought it means that you can safely open older documents (even if that means converting them), but when you save a document (in this case a pp3 file), you won't be able to open it in previous versions. That won't be a problem, and won't mean you may have any drawback upgrading to v.6. But if you say that I wouldn't be able to open a processed raw image in the new version without re-procesing it again..., well... then that is a problem for a user.

If the revamping of the UI is all about CSS, then I don't understand how difficult it may be. You're C programmers! It's like saying that skating is difficult when you drive a Formula1. I have a moderate knowledge about CSS, and can take a look at it, if you wish. I can't promise that I will be able to help, but maybe I am.

Just please think that we're users, but we're not dummies (like Adobe does).

[heckflosse]

@TechXavAL

In my case I am a Microcontrast tool user, and if I don't use it more often it's just because it's not included in the Post-resize sharpening tool.

That's a good example, why we need to discuss about removal (or not) of tools. In past I also used Microcontrast a lot because it (as you wrote) gives an extra crispness. It mainly does that because it's before the normal sharpening in the pipeline. But as it's after capture-sharpening its effect is much reduced when used in combination with capture-sharpening. I never thought about using it in pr-sharpening. That's a good argument not to remove it, because to use it in pr-sharpening it needs to be available for normal sharpening as well to find the values for pr-sharpening.

The problem is where to draw the line. Can we for example remove the painfully slow EAHD-demosaic (means a user who used it in existing pp3-files would have it automatically replaced by another demosaicker but with a slightly different output)? Or do we need to keep EAHD to be fully backwards compatible?

[TechXavAL]

@heckflosse

The problem is where to draw the line

Well, as I see it the problem is not where to draw it. If a line has to be drawn (add all the good reasons you wish here), then it has to be drawn. Stop. My concern is about who is drawing it. You, as developers have full right to do so, but I think (I hope) that we, users, also have something to say. I agree that in the end it will be you (developers) who will take a decision, but first let us (users) say what we need, and what we wish.

[heckflosse]

@TechXavAL

but first let us (users) say what we need, and what we wish

Of course we welcome all user feedback :+1: . That's why I started the discussion already now where it's still a long time to rt 6.0

[TechXavAL]

I've been thinking about the obsolete demosaicing algorithms, and perhaps there's one solution not as hard as it may seem: let's say you all agree that, e.g., EAHD should be removed in v.6, for everyones good mental health.

Fine, then you can do what most programming languages and many apps do:

• you can post an announcement in discuss.pixls.us previous to v5.9, where you state that certain tools and/or parts of them will be removed in the next major release (v.6)
• next thing to do is adding an alert icon next to those tools/parts of tools in the UI of v.5.9. When you hover those icons, RT will show a tooltip explaining that you are safe using them in this version, but in the next version it will be removed and any image processed with this deprecated parts of RT won't be rendered properly.
• in v.6, whenever one of those images gets loaded a helper of some sort (most likely a dialog) will ask you to change definitely the offending tools (some sort of converter, but user guided)

That should make upgrading less painful.

And about the user feedback, it's not likely that a plain user will somehow get here, register on github and post what he/she thinks. Most probably this discussion will never exist for most of them.

One option to overcome this problem is posting a poll/discussion/announcement in discuss.pixls.us asking for opinions (non-binding) that would help you choose what should be kept and what not. And that discussion should come before the previous commented post about what would be removed in v.6.

That is, you may start asking questions to the users sometime after v.5.8 has been released. There's enough time, but it's better that people starts thinking what they won't be able to use in a not-so-distant future.

[snappyapple632]

Or better yet, use the RawTherapee website itself and social media in conjunction with those announcements/polls to help gather more opinions, because like GitHub, only a select number of users go on discuss.pixls.us on a regular basis.

[maboleth]

I don't wish to interfere in this discussion: a plain user here. I came here by chance, and maybe I have something to say.

You're discussing about removing tools because they are seldom used, or not used at all. I agree, but I would frown at a decission taken without asking the users, those that you try to please.

In my case I am a Microcontrast tool user, and if I don't use it more often it's just because it's not included in the Post-resize sharpening tool. You say it's currently only useful with non-raw files (because we already have Capture Sharpening), but if you remove it, then RT will automatically have less appeal to me (or others), because to give an extra crispness to a final/exported image, I would have to open it in Gimp, while I could just open it in my beloved RT and 2 clicks away I would have my image.

Microcontrast is just an example. There may be other tools with the same problem.

Why not working in the UI, putting together similar tools, perhaps with a combobox to select which one to use? If they do mostly the same, then a knowledgable user should know which one to use and how to choose it. If it's a newbie, then give that user a default tool (probably the most current one). If that newbie wants to learn, then point him to Rawpedia.

About «backward compatibility» I've always thought it means that you can safely open older documents (even if that means converting them), but when you save a document (in this case a pp3 file), you won't be able to open it in previous versions. That won't be a problem, and won't mean you may have any drawback upgrading to v.6. But if you say that I wouldn't be able to open a processed raw image in the new version without re-procesing it again..., well... then that is a problem for a user.

If the revamping of the UI is all about CSS, then I don't understand how difficult it may be. You're C programmers! It's like saying that skating is difficult when you drive a Formula1. I have a moderate knowledge about CSS, and can take a look at it, if you wish. I can't promise that I will be able to help, but maybe I am.

Just please think that we're users, but we're not dummies (like Adobe does).

I agree with this. I use Microcontrast as well. I think that module is specific to certain images and occasions, but gets the job done when needed. I would vote against, NOT to remove it (please don't :-) ).

On the other hand I think it would be safe to remove super slow demosaicers. So +1 from me on that.

P.S. I'm generally against of removal of any existing features, except when they are deprecated or very slow/underdeveloped. Or when you make something advanced that has a certain feature built-in.

So, unless something really chokes RT and its optimizations, I'd leave it as-is.

[heckflosse]

@maboleth

I use Microcontrast as well.

I also used it a lot before I introduced Capture Sharpening. Then I stopped using it, because its effect was much reduced when using Capture Sharpening. After the recent comments in this issue I started to use it again and I agree it should not be removed.

Though I still think we could remove some of the slowish/never used bayer demosaicers or at least provide a gui where these are not available.

[maboleth]

I also used it a lot before I introduced Capture Sharpening. Then I stopped using it, because its effect was much reduced when using Capture Sharpening. After the recent comments in this issue I started to use it again and I agree it should not be removed.

Oh well, I didn't even see that, I'm using regular 5.7 ver. So I cannot compare those two. Any approx. date when will 6.0 come out?

Though I still think we could remove some of the slowish/never used bayer demosaicers or at least provide a gui where these are not available.

I agree.

[chaimav]

Another user here. Is it not possible to remove a tool from the GUI, but not from the underlying code? That way, if the user wants to re-render an image that used an old tool it wont break the compatibility. -User reopens PP3 -Popup appears that XYZ tool is no longer available. -Options are --A) Keep tool but not to change any parameters. --B) Disable tool --C) Enable recommended replacement (if available)

[blj86]

As a very new user to this tool the idea of simplifying things by removing tools that are not really uses sounds good. I do think total removal (as in pulling the code) tends to not be the most ideal way. Typically I have noticed most software avoids doing this but the cost is crazy complexity years down the line.

chaimav has a rather good suggestion here but maybe a bit more refined. Assuming tools can be hidden in gtk gui perhaps instead deprecate the old modules that have little use. So for instance say you wish to deprecate edges and micro contrast. They can be hidden in the gui, however in preferences you can add a checkbox to enable deprecated modules which can also warn users that they may go away in the future and are no longer being maintained.

The main issue with this approach is how will the pp3 files work with those tools enabled for one person but not another person. Which is where chaimav's pop up can come in handy. If those modules are present the pop up can simply ask do you want to enable deprecated modules yes or no. If no the raw processor just ignores the modules if yes the tools are enabled and rendered.

This way it is the choice of the user to use unmaintained modules or not and still frees up the developer resources and now the users know if they have a problem with one of said tools that problem may never be fixed because it is now deprecated in favor of newer and better methods.

I guess this is kind of a compromise approach the only main downfall is it won't slim down the code base just make it worse probably... But still a thought.

[TechXavAL]

the only main downfall is it won't slim down the code base

Well, as I see it, that's not the only drawback: if you keep unmaintained code just to allow a user to open the tool used years back, then it will lead to problems, for sure. One possibility is that simply by turning on the old tool, RT crashes because the old code of that tool is no longer compatible with the current engine code.

We are in v.5.8, so there's yet one extra version to be released before v.6.0. Wouldn't be a reasonable idea to add all those tricks in v.5.9, while at the same time RT warns the user about a tool being deprecated in v.6.0 each time it is used?

The question is: which tools are not used, which tools are obsolete, and which tools are safely replaced with other current tools? Isn't it worth opening a poll in a place with more visibility than github? I mean, how many end users are coming here to read this discussion?

[maboleth]

Well if it's of any use here, LR still supports old engines, just because many files were developed using old systems so having backward compatibility is necessary.

On the other hand, I don't know how RT handles those tools or modules. Maybe there should be an intelligent transitions here, so if RT 6.x detects old tools in a pp3 file, it automatically translates those values to new tools. Also providing a note to the user that their images have been developed using obsolete tools and newer ones were being applied instead. Of course, nobody can expect exactly the same outcome in that transition.

But RT crashing just because old/obsolete pp3 has been read should never be an option.

[blj86]

The question is: which tools are not used, which tools are obsolete, and which tools are safely replaced with other current tools? Isn't it worth opening a poll in a place with more visibility than github? I mean, how many end users are coming here to read this discussion?

This is a good idea most of the user base I would think is on disscuss.pixls.us so maybe a poll there assuming one could be made.

Well if it's of any use here, LR still supports old engines, just because many files were developed using old systems so having backward compatibility is necessary.

This is a little easier for lightroom to do because most people don't use sidecars so all of the adjustments are in the database so it is handled in the migration upgrade. Even if sidecars are used the adjustments for those sidecars are just taken from the database and get rewritten after the migration. I think the multi engine approach would just lead to crazy bloat in the long term.

When I was using lightroom I was glad it was there. Lightroom does hidden exposure compensation and contrast adjustments and the only way to remove that and get a linearish file was to use those processing modes to remove the adjustments and make a preset.

On another note about tool removal what about removing the Soft Light tool? I am not sure how many people use this and I know it works slightly differently but I find Local Contrast and Wavlets to be a better option. Usually if I need to use a soft light type blend for something I just do this in a raster editor which gives you much more control over the type of effect you get.

[maboleth]

Soft light tool? I use it in almost every image I process! It's a great and fast option to bump your contrast and colours similar as the SL layer in gimp/ps.

Like, please don't touch it, I'm so happy we have it there, applying it in a breeze to a bulk of images.

On Sun, Apr 19, 2020, 5:03 PM blj86 notifications@github.com wrote:

The question is: which tools are not used, which tools are obsolete, and which tools are safely replaced with other current tools? Isn't it worth opening a poll in a place with more visibility than github? I mean, how many end users are coming here to read this discussion?

This is a good idea most of the user base I would think is on disscuss.pixls.us so maybe a poll there assuming one could be made.

Well if it's of any use here, LR still supports old engines, just because many files were developed using old systems so having backward compatibility is necessary.

This is a little easier for lightroom to do because most people don't use sidecars so all of the adjustments are in the database so it is handled in the migration upgrade. Even if sidecars are used the adjustments for those sidecars are just taken from the database and get rewritten after the migration. I think the multi engine approach would just lead to crazy bloat in the long term. When I was using lightroom I was glad it was there. Lightroom does hidden exposure compensation and contrast adjustments and the only way to remove that and get a linearish file was to use those processing modes to remove the adjustments and make a preset.

On another note about tool removal what about removing the Soft Light tool? I am not sure how many people use this and I know it works slightly differently but I find Local Contrast and Wavlets to be a better option. Usually if I need to use a soft light type blend for something I just do this in a raster editor which gives you much more control over the type of effect you get.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Beep6581/RawTherapee/issues/5555#issuecomment-616156102, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS2NQBGDPXOGGMDARB6D5LRNMHFNANCNFSM4JV4G6KA .

[chaimav]

I use the soft light tool frequently as well. Please keep it.

[dimonoid]

I apply edges to almost all my photos. Please don't remove it.

[virxkane]

1. remove some demosaicers (AHD, EAHD, HPHD)

+1

[beling]

Another user here. Is it not possible to remove a tool from the GUI, but not from the underlying code?

Another user here. I do think that this is great idea. What's more, it would be great if it was possible to choose which tools to show/hide in the settings (with possible default sets of tools/presets: "for beginners" and "for experts"). For example, I would love to hide all the tools from the advanced tab (then the tab itself should also be hidden). At the same time, after opening a file that uses any of the hidden tools, that tool should be visible.

[martbetz]

For what it's worth, all of the tools you're planning to remove (except for the demosaic options) I make use of extensively - my entire workflow depends on them. I realise I'm in the majority, but it would mean I wouldn't be able to upgrade to 6.0.

I understand the logic and respect any decisions made, but it WOULD cause major issues for me personally — I can see how some would view the tools as redundant or duplicated, but that's not entitely accurate in my experience — there ARE differences, and I can't exactly replicate the results to my liking using any of the other options. I've used these tools to provide a very specific style to my images — removal of these tools would at best result in an extensive effort on my part to get similar results I'd likely not be entirely happy with or at worst having to sacrifice any potential new featutes, fixes and support offered by upgrading.

Again, I understand everyone's point of view and this is most certainly not a critisism in any way at all — I just needed to let you know how it would effect me personally, and maybe there are others in my situation as well.

[MALobosR]

Greetings, A user here. On the subject of removing some tools, I think the variety of tools and the precision that someone with a mastery of technique and theory in image processing can achieve is the hallmark of RawTherapee. What I suggest is to create two sections: a basic one for users who are looking for quick development and retouching (with local tools) and an advanced one with tools that already work at the pixel level. While I'm here I'd like to make another suggestion for RT 6, creating a library or catalog system that stores editing data in one place and individual secondary files can be generated as an option if needed to move images to another computer. . thus avoiding the problem of visually doubling the number of files per folder, maintaining order in the photographic archive and reducing visual noise.

[Lawrence37]

@MALobosR Both of those exist in some form.

For tool separation, there is an Advanced tab which contains complex tools and a Favorites tab which can be configured to have a small set of simple tools for users who want a basic feature set. Tool removal is not just about user experience. It reduces the maintenance burden and makes implementing some new features easier, for example.

To de-clutter image directories, you can tell RawTherapee to save and load processing profiles in the cache.