What @afre was referring to (@afre, correct me if I’m wrong here) is that the LightRoom creative cloud thing has driven a lot of folk to try the open-source alternatives; they try to do the same with RawTherapee, and when they don’t get the same rendition, they come asking for help. It’s okay, the folk here are generally helpful souls.
You’re going to come to two realizations:
What ACR’s ‘auto’ button gives you is one rendition, and it happens to please your sensibilities. The other sofwares can do similar, but they’ll be different renditions, so you can’t expect them to look identical.
The open-source softwares are less about doing the work for you and more about you making intelligent choices in your processing. At a minimum, you’ll eventually have to learn about tone curves in all their manifestations, from level sliders to control-point shaped curves, in order to get control over your raw data. What you’re doing in that learning is freeing yourself from the ACR programmer’s opinion regarding what your image is to look like, and taking control of it yourself.
Your difference endeavor intrigued me, so I attempted to duplicate your ACR JPEG in my hack software, rawproc. I did it there in order to completely eliminate any hidden processing, and then explicitly apply what it took to approximate the JPEG. Here’s the compare screenshot, the rawproc working image on the left, the ACR JPEG on the right:
If you can read the commands pane on the right, it’s the camera color profile, the camera black subtract, the camera white balance, and @heckflosse’s AMAZE demosaic implementation, then a black/whitepoint scale of the raw data to fit the display black/white. That’s about as close to “Neutral” as you can get to obtain a starting raw image. So, the tool you see displayed in the bottom-left is a tone curve, and this is what it took to make the tones approximate the JPEG. I think your perception of sharpness may be differences in contrast.
Now, this isn’t really a fair comparison, because saving to JPEG does its own changes to the image. Here’s a JPEG-JPEG screenshot:
Well, I don’t use LR, I find it so uncomfortable. I use ACR, which uses the same API as LR, but differently. ACR offers me a nice starting point - according to my taste.
Regarding the software… There are technical guys and simple users, who don’t need such refined details. They need simple controls, as a few sliders… This is the reason why powerful tools are not easily adopted these days, and thinking to those simple users needs consistent efforts, with the gain of having an increasing user base. This is the story of Linux, Linux DE’s and lots of free/open software. In time, the first impression remains in their heads and won’t come easily to use software that made them suffer once.
Now, what I have struggle with here, was, in part, the unresponsiveness of the edit boxes and made me think they have no effect. Some timer to decide the user have ended editing some value and start applying it would be nice.
On other hand, to help the migration, also my case, some profile for the initial automatic processing, with a very close result to some common commercial tools used these days, is very useful. You give to the new users something familiar that makes them stay. Just my two cents…
@msdobrescu The fact, that I had to adjust the raw white point, means that the white level for your camera is probably not correct in RT. Can you provide some completely overexposed raw files from your camera using filebin.net and post the link here?
I did something, which usually should not be necessary if the white point for the camera in RT is correct. If the white point from dcraw or camconst.json is too large you get this pinkish tint when applying negative exposure compensation. In this case the white point was too low, means, to recover as much highlights as possible, I increased it by reducing the value of the white point correction adjuster until it was too much (pink) and then increased the adjuster value again by 0.01.