If you’re using the Lens IDs from Libraw, I found a problem in the bleeding edge Libraw commit from github - it rendered a different number than what I know for my Nikkor 18-200. Reverting to 1.19.5 fixed it.
2 Likes
No, I am not using LibRaw in my code… the EXIF data is extracted with EXIV2, and then the matching with the LensFun DB is done with some code inherited from DT. I must have introduced some bug in this part at some point…
Anyway, thanks for the suggestion!
1 Like
I’ve tested the aspect ratio preservation in the Crop tool (in stable dac46), and it is working now. Thanks.
2 Likes
In fact, at least for this specific lens the LensFun DB specifies a minimum crop factor that does not match the D7200. RT applies the corrections with a warning, PhF is more conservative and does not allow to apply the correction, unless you select the lens manually as I have previously shown.
Here is the message shown by RT 5.7 on my system:
I have finally committed a fix for the custom black/white levels, they should work properly now. For the specific example of the morning mist image, a white level of 13577 seems to be a good choice…
Sorry for taking so long.
The custom white level seems to be working now. The custom black levels still have problems on some files. For example this one - where making any change to the black levels (including clicking the individual slider reset button) results in nan values. However, I don’t think I have ever had to change the black levels on a file.
1 Like
Indeed there is a problem with Nikon files, in which the black level is subtracted in-camera and therefore it is zero at raw processing level. I will investigate…
@afre @bc_the-path @paulmiller
I have started adding tooltips to the various UI controls. Currently only the RawDeveloper module is done, the rest will follow step-by-step. I have also improved the layout of the lens corrections widgets in the raw developer module:
Any comment is welcome!
1 Like
1 Right now if we wanted to change the lens we would have to go through a set of menus. A search bar would speed up the process and make it more accessible. Same with the new layer module (as I have suggested a few times in the past).
2 I am still uncomfortable with the clip negatives option. I really think that there should be gamut compression feature there, which I think you have the code for, because discarding negative values would produce bad pixels, which would adversely affect their neighbours and operations down the pipeline.
1 Like
How can I download the current Appimage? Can’t find it… perhaps too sleepy…
The V0.3.0-rc1 appimage is already available, while the one from the stable branch is being re-built right now…
I totally agree, but seems to be easier to describe than to actually implement in GTK… I am trying to figure out how to do that in practice.
That’s a very good idea, and fortunately easier to implement that suggestion #1, so I will start from this. I would also propose to implement the possibility to perform gamut compression separately for negative and >1 values, as the latter are not necessarily a problem in the early stages of the processing pipeline, and need to be addressed only when preparing the image for output.
1 Like
Yes, that is why I am only asking about negatives as they are a problem once they are generated.
1 Like
This message is just to let you know that I have not forgotten your request, but that it turns to be actually a bit trickier that I initially thought, mainly because the pixels with negative RGB values might also have a negative luminance, which makes the gamut mapping less trivial…
The forum is reminding me that I am posting too much. 
Deleted a bunch: hope it doesn’t affect the flow.
Where does this happen in the pipeline?
Related remarks
– I used to inpaint pixels but abandoned the practice because it can make it worse.
– I wonder if you could use the raw data or embedded preview image to estimate the luminance…?
– In my experience, negative values tend to surface in the dark regions. In RT, at least for Urban Nightscape | Cape Town, they show up about saturated light at point sources (traffic and vehicle signal lights), though @heckflosse told me that he didn’t have that problem.
Negative values appear after converting from the camera colorspace to the working one
I would not use the preview image, because it varies from camera to camera and depends on the actual camera settings, and also because we should be able to do better in post-processing…
Yes, they typically appear in bright, highly saturated and monochromatic light sources.
I wrote raw data or. 
With PF, I have only seen it in dark areas.
In some special case there could be negative values in camera rgb color space due to processing like demosaicing according to
https://github.com/Beep6581/RawTherapee/issues/5561
And in the XYZ color space after the matrix conversion from the camera rgb.
After running some tests i think that generally negative values should be clipped:
-in camera rgb before the conversion to XYZ
-in XYZ after the conversion from camera rgb
Dear all,
while I have not yet implemented a good gamut compression method for negative values appearing after conversion from the camera matrix profiles, I have just committed a fix for a nasty bug that was present since a while in the layer drag 'n drop functionality. The bug prevented in some cases to move certain layers upwards in the layer stack, and the only solution was to delete those layers and re-create them in the correct place. Now drag 'n drop should work correctly again.
Please let me know if you still see some odd behavior when moving layers around…
As usual, new packages will soon appear in the continuous integration release.
Just tested on Windows 10 (64 bit).
Drag and drop works fine now.
You can now drop easily any layer to the upmost position in the stack.
Just noted 2 bugs:
- if you open, by error, a .pp3 file (by RawTherapee) PhotoFlow immediately shut down.
- if you delete by error, the raw developer layer, most of the time, PhotoFlow crashes (IMHO this specific layer should be hidden or not “deletable” by right-clicking…)
EDIT, just a further question…
When you activate very fast, not on purpose I mean, the same tool twice, thrice etc (by error or for whatever purpose) you end up with plenty of their corresponding windows in the GUIs…
Shouldn’t be only the last window necessary (kept, I mean) and the other ones “automagically” closed?
I understand it can make sense to have more windows showed on the GUIs, for instance with the “basic adjustments” tool, but this approach looks redundant in other istances.
Yep, I am aware this is not a bug because you, as an user, are supposed to close them manually before repeating the same tool 
See this screenshot for the crop tool:
