This is possible, however, I personally much prefer you don’t make assumptions on what we can or can’t or won’t do. Please throw things at us and let us (read: RT devs) decide if it’s worthwhile or not.
Even if things stay in the tracker for years, doesn’t mean they will be forgotten.
3 Likes
I like this attitude. Just trying to help the OP understand why there might be some resistance to his suggestion, when on the surface it seems like a sound request, and is experienced by many users.
2 Likes
In dt, it is visually obvious that the power button is a power button both when is is off and when it is on. In RT, that is only true when it is on.
2 Likes
I’ve been using command shells for a looong time now, so my perspective is appropriately biased…
There’s an efficiency in the bare ability to assemble processing ops into a chain without burden of click-this drag-that that I can’t readily convey. Also, that chain is readily regarded, without adornment of <xmp:this></xmp:that> or other encoding obfuscations. For instance, here’s my default raw processing chain in rawproc:
colorspace:camera,assign subtract:camera whitebalance:camera demosaic:ahd blackwhitepoint:rgb,data
This delivers a linear, appropriately scaled rgb for further processing using the camera-supplied/looked-up white balance, black subtract, and color parameters. I can use this chain in an img command line, or in rawproc’s input.raw.default property. G’MIC and it’s ilk were the inspiration for this, as I really learned a lot early on from just running commands against my images with various combinations of operators.
There’s nothing like a batch tool to process the large quantity of raws from a day’s shooting. And I find a command-line environment to be the most effective way to wrangle that.
2 Likes
I unintentionally seem to have stirred up a hornet’s nest here. For one, I was not aware the actual devs were lurking in these premises (that’s a HUGE bonus for its users, so big kudos to you guys for doing that, btw!). Secondly, the smirky comment was meant as a tongue-in-cheek comment to something Glenn wrote 
It was really not mean as a bug report. I maintain a few open source libraries and know how vital a detailed bug report is. You are absolutely right that wasn’t the best way of setting the tone for a newcomer.
I’ll try to tread more carefully in the future, being the rhetorical elephant I can be.
With regards to the UX thing, it’s mainly tainted by the design thinking in the integrated dev-design teams I have worked with in the past: design for easy adoption, allow for adaption. It’s also based on maintaining software libraries. When you see bug reports on your API from new users that’s caused by it trying to cater to too many fringe/specialized needs, you often rethink the API to cater to the UX of the new users, as the early adopters often represent the tech elite, rather than the vast majority of potential users. Striking a balance is hard, of course, but making the common cases easy and the complex possible usually caters to both. The techies/power users can live with toggling some setting, while new users probably leave long before knowing it exists.
4 Likes
Absolutely, point taken. Sorry for the rhetorical belly-flop (it’s common where I come from) 
2 Likes
We do welcome feedback, but you should certainly get to know the application a little bit before you start making requests. Raw processing and image processing are complicated, and I think the general UI ethos of the applications you’ll find here is a bit different than the commercial counterparts. We have no markershare to gain, no stock holders to please; if the people using the application were limited to the people here, we wouldn’t be displeased. We write tools to please ourselves first, not a product manager or other people.
Adobe has done a great job at dressing up the complexity of imaging into single sliders, but we think different. I think in general most are math/science oriented, we enjoy knowing the reason why things work they way the do, we enjoy flexability and control eve when it costs us ease of use, and we don’t stray from the math and science in our UX/UI.
We are aware this isn’t for everyone. There are reason to use other software and you should use the tooling that suits you. We are not trying to appeal to the masses and we probably never will. We are OK with that.
3 Likes
I wonder how many RT users are out there. Is it hundreds, thousands or tens of thousands. Are the majority really “math/science oriented”. Perhaps you’re right yet we might never really know.
I am not “math/science oriented”. I was looking to get away from subscription based software since I am a hobbyist and not a professional. RT as a RAW processor is hard to beat. That was the draw for me though I do find that the workflow is just so frustrating and time consuming at times. But, that’s just me.
1 Like
Hello, I understand your frustration but I have good news for you. RawTherapee is not difficult to use, you must just take some time to find out how it works, that’s all. Read rawpedia to find out some basic ways to process raw files, then read a bit around in this forum, try a lot yourself and you’re done!
1 Like
Oh really!
Exposure Tab First Steps:. . .
## Lightness
This slider applies a hard-coded tone curve to lift or lower the tonalities of the photo, resulting in a more or less light image. The same tone curve is applied separately to each R, G and B channel. The black point and the white point keep their positions.
## Contrast
This slider increases or reduces the contrast of the photo. It applies a contrast curve centered at the average luminance level. Tonalities above the average are lifted (lowered), while tonalities below the average are lowered (lifted). The same contrast curve is applied separately to each R, G and B channel.
## Saturation
This slider makes the photo more or less saturated. In more technical terms, it adjusts the saturation of the image by applying a multiplier to the saturation level of pixels in the HSV color space.
LAB Module. . .
## Lightness
When using the Lightness slider in the Lab section, a tone curve is applied to the L-channel of the Lab color space. As with the brightness slider in the Exposure section above, the black point and the white point do not move.
## Contrast
The contrast slider in Lab increases or decreases the contrast of the photo, again applied to the L-channel. In developer’s terms: this slider applies a contrast curve centered at the average lightness level. Tonalities above the average are lifted (lowered), while tonalities below the average are lowered (lifted).
## Chromaticity
The Lab Chromaticity slider increases or decreases the chromaticity of the image, by applying a contrast curve to the a- and b-channels of Lab space. Setting this slider to -100 removes all color, making the image black and white. The best way to convert an image to black-and-white is by using the dedicated and powerful Black-and-White tool in the Color tab.
Well, when you place Lightness, Contrast and Saturation on the Exposure tab along with the LAB module with Lightness, Contrast and Chromaticity on the same tab, then it’s no wonder that folks like myself find this a difficult way to work.
RawPedia doesn’t explain the differences as to where to use one over the other. Is there a video out there that explains where to use one over the other? Is one better than the other in all cases. If so, then why offer both. I find this confusing at best. Then again, that’s just me.
I think you are correct that RT has a steep learning curve, and that the documentation is not oriented towards helping newcomers.
I think of rawpedia more as a reference manual than a user’s manual or tutorial. You have the perspective of a less technical user, and that is very valuable, because once you master something, then you tend to forget how hard it was to get there. I’d encourage you to contribute to rawpedia, write blog posts, tutorials, videos, etc that address what you find currently missing.
For learning, this forum is invaluable. There are also more and more RT videos on YouTube, for example from Andy Astbury.
2 Likes
I have watched all of Andy’s videos, many times more than once. His extensive knowledge of both Adobe software and RT is what keeps me going.
I am not familiar with RawPedia write blog posts at all. Perhaps you could direct me to that. I am not knowledgeable enough to do videos and tutorials. All I know is that there should be a way to satisfy the technical users and those like myself at the same time. Right now I don’t see that.
Anyway, I think that this discussion has gotten off topic.
I don’t doubt this. I don’t question their efficiency, nor their appeal for users comfortable with command line - they obviously serve an intended purpose for the creators. Only amazed at the amount of effort put in, to appeal to such a narrow audience. Not saying there is anything wrong with it - indeed I hope to start utilizing those programs in time.
1 Like
@fatso83 @gaaned92 @paperdigits @elGordo @Soupy @stuntflyer and basically anyone flustered by RawTherapee’s ‘unconventional’ GUI, please see GUI changes: highlight enabled modules, RawTherapee theme CSS clean-up, minor tweaks by Thanatomanic · Pull Request #5929 · Beep6581/RawTherapee · GitHub
Any comments are welcome, let me know what you think. Does this improve the UX?
6 Likes
For me it does 
1 Like
Likewise.
Is it difficult to compress the overall height of the active window by closing the gap between the sliders, etc. and to decrease the height of the active blue bar?
1 Like
Not difficult, but there is a careful balance between compactness and clarity of the options. I found the current RawTherapee theme a little too compressed and therefore messy, so I opened up things a bit. I can try to compress it back a little.
1 Like
All the layout/alignment changes are excellent. Nice work!
For the module on/off status, I tried to put myself in “this is my first interaction with RawTherapee” mode, both as someone who at least read Getting Started in RawPedia and as someone who just installed and launched the package and tried to figure it out by poking around.
The on/off controls are referenced in the fourth paragraph of “Edit your first image” on the Getting Started page, including a little visual of the controls. The text doesn’t hit the reader over the head with the fact that tools tend to be “off” initially, and using their controls will have no effect until they are turned on. Common sense would suggest people would realize that, but it seems that this must often be explained. I think most users that read Getting Started should be OK, though.
For new users that just jump in without reading anything, it’s another story. If the user opens his/her first image, and all the tools they see are powered off, e.g.,
it’s not obvious that the 
is a power button. I suspect that this leads to a lot of the misunderstandings, and I think using a dimmed power button as darktable does for a powered-off tool would reduce the number of confused new users.
I once owned a BMW; was glad to sell it because, among other things, I couldn’t easily decipher the iconography on the switches. Can never assume what you understand is what others understand. Okay, with the car, can’t discount the operator…
1 Like
Good work @Thanatomanic . What about turning on a tool automatically when any of its settings are first changed?