Could you please check with the latest windows version? There might have been a problem wit the packaging of the lensfun database in the windows case…
I have also implemented the possibility to move the histogram to a separate dialog.
IN addition, I have changed the behavior of the image samplers. When a sampler is disabled, its position is “forgotten” so that it must be placed again next time it is re-activated.
This way it is possible to “recover” samplers that get lost, for example because the image has been cropped. It also allows to disentangle two overlapping samplers.
The changes are available in bot the stable and v0.3.0-rc1 branches.
Great: more items from my checklist. At least the camera is recognized now, though distortion correction is still unavailable. It works in RT e.g. When it works, RT (or dt) usually does a better job. Something to look into in the future.
It would be great if histogram started out larger (1/5 of screen?) and both it and samplers got the x close button at the top instead of Close at the bottom for consistency and convenience.
Lastly, it still takes extra long for the archive to extract. I have gotten used to it but compared to other FLOSS apps it is an outlier.
I have reproduced and fixed what you describe. Could you test the latest packages (will be ready in about one hour) and confirm the fix, whenever you have the time?
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.
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…
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.
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…
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.
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:
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.
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.
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.
Deleted a bunch: hope it doesn’t affect the flow.