Thank you Morgan, it’s the same point suggested by TooWaBoo.
Unluckily I can’t deal with antialiasing. It looks like just horrible for me.
I don’t have any issues with my system and all my programs, I don’t want to blur fonts to see better (but still bad, because antialiased) RT and crappy all the rest.
I already tried to deal with Cleartype when a chrome update forced antialias and, after I uselessly lost a lot of time, I simply decided to move back to the old version.
With RT it’s luckily better because there is a workaround.
The problem is dependent on your hardware and software. Glad you found a workaround. Zurich is an older typeface, so it is probably designed to look nice in a variety of situations.
If disabling sub-pixel rendering (“Cleartype”) in Windows does not disable it in RawTherapee (after having restarted RawTherapee), then file a proper bug report.
A little late to the party, but another round of thanks to the devs for making this next iteration of RT possible. I’m especially looking forward to making use of the favorites tab. As I continue to refine my workflow, I find that there are a few features that I use each and every time. It seems that having them in one location will save a lot of clicking around.
@ bluc
As mentioned above, this might be a subpixel rendering issue. To be more precise, it seems like you might have specified the wrong subpixel layout, but i’m not sure about that. If the subpixel layout is not chosen right or some other aspect of subpixel rendering is not set up correctly then it’s no wonder that the antialiasing looks bad to you. Maybe if you check that it turns out that (properly working) antialiasing is actually quite ok for you?
Another aspect is that I too think that antialiasing without subpixel rendering looks quite blurry. But when subpixel rendering is used (correctly) then everything looks almost as sharp as when antialiasing isn’t used at all (at least for me).
Thanks to you too, but I already have spent (I mean lost!) a lot of time about this issue when I had the same problem with a web browser. At that time I tried every kind of guided and/or manual settings.
I just don’t like antialiasing.
Is it just me, or has the RT 5.6 luminance noise reduction been improved? It looks less artifacty and more intelligent in differentiating detail and noise.
Hmm, looking at the commit history of denoise-code I can’t confirm.
Maybe a side-effect of a third-party library. RT luminance noise reduction uses fftw for example.
As I still have 5.4, 5.5 and 5.6 installed, I tested on the same raw image ensuring no sidecars present.
Only used Exposure Auto Levels button and then only changed Luminance in NR to 60.
5.5 and 5.6 indistinguishable but both much improved on 5.4. Not subjective, major difference in histograms.
I forgot that I hadn’t used 5.5 much so my comparisons were between 5.4 and 5.6 being the only versions I’ve used much.
Just noticed also that I’ve lost my Favourites tab so will need to set that up again! Think I should clean up and stick to 5.6
Like I said, may just be me. I was curious if a change was actually made or not. It is possible that any difference is a figment of my imagination, as I haven’t done any serious scrutinizing, let alone a blind ABX between results.
Same with me, and I am not particularly ideologically inclined to only use FOSS software. I could be doing Lightroom or Capture one, but I find Rawtherapee to be more powerful.
Just installed 5.6. Fonts look good. For what its worth, as with 5.5 I had to manually edit my Win7 registry to get RT to show up as an option on the Win Explorer “open with” dialog. And like 5.5 it causes my system to hang for a few seconds when I close RT, and also has that separate DOS dialog window show up which I have to manually close. These are elements in my environment that were not present with RT 5.4
Maybe it’s this issue which especially shows up on windows:
assume your number of cached thumbnails is (default) 20000 and you already have 20000 files in thumbnail cache folders.
Now open a folder (let’s say with 200 files), which’s files have no thumbnail in cache
At opening the folder the thumbs for the 200 files are generated and saved to thumbnail cache
When closing RT, it counts the number of files in thumbnail cache (now 20200) and checks for the 200 oldest ones which have not been used. That’s a very expensive operation (at least on Windows) because it has to get the information of all 20200 files to find the 200 oldest, which then will be deleted.
To check if you ran into this issue:
start rt
close rt
start rt
close rt (should close fast now because the number of chached thumbnails didnt change)
@JimPlaxco If the scenario I described is the one you ran into, I already have an idea to improve the behaviour
Edit: The point is, if yoy use RT to open a single new file, while the thumb cache already has 20000 files, rt will need to check 20001 files in cache to remove the oldest one when closing rt.
By allowing the thumb-cache to exceed the defined size by for example 1% this could be reduced to a slow closing of rt only every 200 files.
Example:
Cache has already 20000 files
You open a new file which is not in thumb-cache by using open with rt
The thumb will be added to thumb cache
you close rt
because the tumb cache size increased by less than 200 (1% of 20000) the cache will stay as it is
.
.
.
xxx) You open the 200th new file
xxx + 1) You close RT
xxx + 2) now the 200 oldest cached thumbs will be removed (which is still expensive, but will occur much less often)
I like the idea in general but I’m no fan of overcommitment. But 99% as a target size would solve that (subjective) concern.
But how about switching our cache eviction strategy from FIFO (20200 stat()s when evicting 200 entries) to random (0 stat()s) or 2-random (400 stat()s)? Shouldn’t hurt that much when opening a folder. Plus: there is a higher expectation that opening a folder takes time than that closing RT takes time.
