Menu
▾
▴
#219 colors are picked from the wrong position if lensfun is used
Using lensfun the color are picked from the wrong position. There was a partial cure during the last days, but this worked only for RGB using the data from the last_phase. It did not work for the white-balance or adjustments.
Therefor I suggest:
1) use in render_preview() the RGB-data from the last phase before lensfun and the raw-data from the first phase
2) change calculate-spot to make an inverse lensfun correction for the spot-coordinates.
A diff is attached
It seemed to be, that this cured the crashing of the adjustments with the cvs-version an 2009-11-01 09:00 UTC.
There still remains another crash with lensfun:
I scaling to minus-values ufraw crashs if zooming in.
correct spot issues with lensfun
Once lensfun_phase will be moved to its rightful place before develop_phase, the solution to this bug will be much simpler. Just read the spot data from the lensfun_phase image.
Udi
Well, it is correct, that once lensfun in its rightful place, all will be fine. But for the time beeing, an intermediary solution should be achieved (that was what I was working on).
And as well in the svn-version from this weekend the information for render_preview() was used from the buffer of the final phase (even the raw). I suppose, that this is only correct for the RGB-values but it delivers wrong data for the y and the zone (and maybe a reason for the crash of the adjustments??)
Hopefully, the lensfun phase will be put in place in the next few days. The patch that I just applied is a step in that direction.
Udi
This are very good news, thank you for your work.
May I suggest to keep the lensfun-phase for further uses for all additional steps working in working-color-space RGB?
After doing some "research" about workflow needs, for me some additional methods are missing. The main one would be a local contrast enhancement. This can be achieved in gimp also, but it includes changing the tonality of the image and it may be better do it in 16 bit depth before going to gimp.
According to an idea on luminouslandscape I would suggest to implement a kind of unsharp mask with a very large radius. This calculations need a lot of time (boring in gimp for large images), but have a look for the following proposal (I know, this is a little bit not inline with the manifest, not to invent new):
1) The method: unsharp mask with a large radius (for example > 70 .... to 200) increase local contrast.
2) This should be applied top the L*c*h channels
3) It should be tuneable for the total channel, shadow, highlight
4) I think, we should calculate:
pixel_value + faktor * (pixel_value - weighted_mean_of_area_around)
for each channel and keeping in mind to handle hue correctly
5) the _weighted_mean_of_area_around should be calculated by using a Monte-Carlo random sampling, hopefully we will not very much samples.
This bug got resolved in CVS.
Udi