@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 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.
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.
Yes, that is why I am only asking about negatives as they are a problem once they are generated.
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:
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:
There is a configuration option that allows to keep only one tool dialog opened:
However it seems not to work properly when tools are added very fastā¦ thatās indeed a bug, although maybe not the most critical one. If a tool is added after the previous dialog has been shown, then it works properly.
Yes, thatās part of the things I still need to implement/fix before I can release, that is making sure that the application does not crash in āabnormalā situations, and having ādefaultā layers that cannot be moved/deleted.
Noted.
Is it intentional that you donāt get the Blend mode and percentage controls when you donāt have floating controls enabled? (using Windows, PhotoFlow HEAD-d92d8 (2020-03-01))
Kevin
No, itās definitely a bug!
I have to admit that I never use non-floating controls myself, and I am considering to remove this option for the future, because maintaining the two UI options is rather heavy.
Would you have anything against this? I will probably start a dedicated thread to grab users opinionsā¦
I think if you have to work on the UI twice it would be better to disable one of them for the release and then revisit it later.
I think if you have to work on the UI twice it would be better to disable one of them for the release and then revisit it later.
Totally correct, IMHO
Quite often, when you want to satisfy everyone, you end up instead with displeasing all of them with half-baked featuresā¦
If nothing is critical, I suggest you release v0.3.0-RC1 or RC2 on the releases GitHub page. Look, a visitor to GitHub will likely encounter this.
which is not representative of your hard work since. You have made more than 5 commits and PF is much improved.
