Skin targeting for CBDL (hue curve?)

[Beep6581]

Originally reported on Google Code with ID 2150

Would be nice to have a hue curve for CBDL, same as the one for Defringe, to target
only skin :] Or instead of a curve, some other method of targeting only skin.

Reported by entertheyoni on 2013-12-21 15:58:47

[Beep6581]

The costs for this functionality in addition to the already memory-hungry CBDL will
be at least width*height*4 byte...

Reported by heckflosse@i-weyrich.de on 2013-12-21 23:41:07

[Beep6581]

Memory is cheap, time is not :]
(time spent exporting two versions to other applications just to mask skin)

Reported by entertheyoni on 2013-12-27 13:04:14

[Beep6581]

I am not at home, but in "transit" to my daughter in Paris. I fly on December 31, destination
Cambodia and Vietnam (with friends)... until January 26.

Nevertheless, I think I can take into account the demand DrSlony quite easily and without
using extra memory ...(probably with 1 slider as in Lab adjustements) but it will take
one month 

:)

Reported by jdesmis on 2013-12-28 07:14:42

[Beep6581]

No rush, enjoy your very nice trip! I dream of going there one day.

Reported by entertheyoni on 2013-12-28 14:01:19

[Beep6581]

I returned from my trip to Cambodia and Vietnam .. Nice trip but tiring.

Here's the first patch:

1) acting on the slider, the protection of skin tones is controlled 
2) up to 75, it only reduces the action of CBDL, then from 75 we undertake further
action to take account of the hair, beard ...
3) only in Lab mode (it is very difficult to do in CIECAM02 mode) control of a gamut
is achieved if the box "Lab gamut control"  is checked. This control prevents blackheads
when contrast levels are important.

:)

Reported by jdesmis on 2014-01-28 12:48:28

---

• _Attachment: issue2150_1.patch_

[Beep6581]

Hello Jacques! If you have photos, don't hesitate to post :]

Using http://rawtherapee.com/shared/test_images/nikon_d80_wb.nef I see that the new
slider does separate skin tones from the green background, but actually what this feature
calls for is not skin tones protection, but the opposite - skin tones targetting! So
that skin tones are the only tones which are affected. That way we can use CbDL to
remove blemishes and increase skin texture without affecting the shirt, background,
or anything else.

Reported by entertheyoni on 2014-01-28 14:10:32

[Beep6581]

Hello DrSlony

1) it is a bit of a question of semantics ... If you push the slider to the right reduces
the action of CDBL. If it must be called something else for me no problem, but in this
case what label to?

2) the photo of the young woman seems "yellow" ... Besides the WB settings are special
"Tint = 2.14" is not usual, all the cases I've seen on color skin (documentation on
the subject, other software, ...) never I only went up 1.95 radians (either in white,
black, yellow ....) - the maximum is about 1.65 rad. If you try another setting WB:
"auto" , or with SpotWB, it gets more usual values ​​of temperature and tint (3900--0.951
or 4900--1.125) and a photo more pleasing to the eye.

3) however I tweaked a little function that detects and corrects skin to extend more
towards high values ​​of the hue.

:)

Reported by jdesmis on 2014-01-28 15:03:12

---

• _Attachment: issue2150_2.patch_

[Beep6581]

1- I thought it could have been just wrong wording on the label, but I couldn't get
the CbDL effect to target just the skin while not affecting non-skin (e.g. the green
background).

2- That NEF is a "UniWB" photo. I use the WB picker on her shirt, then the colors look
fine, yet I didn't manage to get CbDL to just affect the skin tones.

3- I will try patch 2 tonight or tomorrow!

Reported by entertheyoni on 2014-01-28 15:38:12

• Status changed: PatchSubmitted

[Beep6581]

My English is still bad and I'm not sure I understand.

The cursor "skin tones protection" reduces the effect of CDbL for hue/chroma/luma skin.
This is essentially the same values ​​for "Vibrance", "Lab adjustements" and "CIECAM"
...

Over the slider is right over the attenuation is strong ... as for "Lab adjustements."

It bothers me to increase the area hue/chroma/luma...and if possible I would reduce
the "skin area" to bring the values ​​of the others ( vibrance , lab adjustements ...
)

Out of all the portraits that I have (including "playraw23_hombre.pef") it works well.
You can put CDbl has very high values ​​which affects all of the image by increasing
the contrast (background, objects, etc..) And maintain the appearance of the skin by
acting on the slider.

Reported by jdesmis on 2014-01-28 15:54:40

[Beep6581]

With the WB default of this photo (camera) T=4276 Tint=2.140, the other functions that
use algorithms "skin protection" have no effect  (vibrance, lab adjustements,..). 
By cons with type settings T=4700 Tint=1.15 everything works correctly.

It is therefore important, but it is obvious that the white balance must be correct.

Reported by jdesmis on 2014-01-28 16:04:26

[Beep6581]

if I look at the photo, it is clear that the young woman is "in the sun". And given
the inclination of the shadow we are close to noon  (exif=14h30 ??).
So we should have a temperature between 4700K and 5500K and a tint between 0.95 and
1.10.

In this case, the algorithm works well (without extended  area).

:)

Reported by jdesmis on 2014-01-28 16:17:30

[Beep6581]

Hi Jacques! Welcome back:)
The patch works as advertised, but would it be possible to make an enhancement. 
To change the behavior of the new slider to either target the skin tones (new negative
values) or to avoid skin tones (as in the patch #2, positive values). At 0 value slider
should have no effect (as in patch #2. 

The label then could remain "Skin Tone Protection".

The idea is to be able to , for example, smooth the skin tones with negative CDBL values,
but leave the rest of the image untouched by CDBL. The global image sharpening can
be controlled via other tools - USM, etc.
What do you think?

Reported by michaelezra000 on 2014-01-29 03:00:33

[Beep6581]

Here the patch that take into account into your requests.

:)

Reported by jdesmis on 2014-01-29 12:46:41

---

• Attachment: issue2134-3.patch

[Beep6581]

With issue2134-3.patch, the "Skin Tones Protection" slider at -100 makes CbDL target
skin-tones only, at 0 it targets everything, and at +100 it targets everything except
skin-tones. Great!

How does as-shot WB and RT's WB affect this?

I suggest renaming the slider to "Skin Tones Targetting/Protection" since targetting
is what happens between -100 and 0, and protection between 0 and +100.
Tooltip: "At -100 skin tones are targetted.\nAt 0 all tones are treated equally.\nAt
+100 skin tones are protected while all other tones are affected."
"

Lab Gamut Control (with CIECAM02 off) had no affect on any photos I tested. What does
it do? If it's not useful, let's not keep it.

I was wondering whether Hombre's pipette feature could be used here, so we could click
on skin and bang!, the slider pivots around that tone?

Reported by entertheyoni on 2014-01-29 14:03:49

[Beep6581]

Here is a patch with the proposed corrections.

The correct white balance is essential for the operation "skin" goes well. Indeed,
the algorithm takes into account:
I oversimplified but it is much more complex
* Hue - basically in a range of 0 to 1.65 radians (red to red-yellow)
* Chromaticity - between 7 and 50
* The luminance of 10 to 100.
But for each luminance, it has a range of hue and chroma.
This is necessary to take into account the different "skin" and the lighting variations.
In addition, each trio hue/chroma/luma has two transition areas.
Depending on each area and each trio leads to a reduction of the action of CDBL.

If the white balance is incorrect, the hue will be wrong (and also, but to a lesser
degree the chroma).

Lab gamut control has effect in extreme cases. For example with "colorspace_flowers.pef",
if you choose "default" and you increases contrast and chromaticity Lab (ex: C=25 Ch=50).

If we apply CDbl with high values, we ​​can clearly see the action of "Lab gamut".

But if you find that these cases are of rare use, I can remove  (or make inactive).

For Pipette, I don't know, I have not yet loaded this branch ... I'm just back from
that two days ... there jetlag ..but I think it will be quite complex, because we do
not go off the algorithm ... certainly we can target the area, but I think there is
work. 
Perhaps the pipette she will better refine the white balance, following the variation
/ distribution of tones in the skin.

:)

Reported by jdesmis on 2014-01-29 16:32:31

---

• Attachment: issue2134-4.patch

[Beep6581]

Thanks Jacques! Sorry I won't be able to try the patch until the weekend...

Reported by michaelezra000 on 2014-01-30 03:57:58

[Beep6581]

No problem...

I will modify the PP3 when we have given an opinion on the need to "Lab gamut"

:)

Reported by jdesmis on 2014-01-30 04:50:51

[Beep6581]

I will test patch 4 later today. By the way, does patch 4 change copy/paste profile
or snapshot behavior in any way? I noticed in patch 3 that the slider's value was either
not copied when I copy/pasted the profile to other raw files, or it was not saved in
the snapshots (forgot which).

Reported by entertheyoni on 2014-01-30 07:02:40

[Beep6581]

Here a patch with :
* batch
* partialpaste
* pp3 with  Version=318

Reported by jdesmis on 2014-01-30 08:45:47

---

• Attachment: issue2134-5.patch

[Beep6581]

Thank you Jacques.
With patch 5, STT/P copy/past/save is still very quirky. I tried copying and pasting,
it worked. Tried partial, it worked. I switched to the next photo, switched back to
this one, it's reset to 0. Tried copy and paste and partial again, now it doesn't work.
I tried this about 20 times, and I can't figure out why it worked - usually it doesn't
work, the value is reset to 0 (yes CbDL is enabled).

Reported by entertheyoni on 2014-01-30 09:22:46

[Beep6581]

After some cosmetics changes and one real change, I think it is now ok ?

Reported by jdesmis on 2014-01-30 10:45:12

---

• Attachment: issue2134-6.patch

[Beep6581]

Hi Jacques, could the transitions be made smoother? Here is illustration where it can
lead to the rough transitions: http://i.imgur.com/ROA5aU6.jpg

Reported by michaelezra000 on 2014-01-30 12:24:26

[Beep6581]

Hi Michael

Can you provide the file  (raw ?)

Thank you :)

Reported by jdesmis on 2014-01-30 12:43:28

[Beep6581]

Some remarks on the skin.

1) if people are white - yellow or black it does not change the hue of the skin
2) it is the same for chromaticity
3) only changes the luminance and distribution

For a given picture, the color distribution of the skin always shows substantially
the same differences in terms of hue.
Basically an amplitude of 1 radian. This prevents the use of a pipette, to assess the
overall hue.

Four phenomena can disrupt the algorithms that will recognize that it is the skin:
1) wrong white balance :  will for example change the color from red to blue and reduce
the chromaticity  (main cause)
2) bad light, for example "Fluorescent" which causes holes in the spectral data
3) noise (chrominance) which causes green blue and red points.
4) excessive saturation settings that will make the data out of the usual values.

I determined the amplitude of the tone and saturation and luminance from:
* Knowledge bases found on the web;
* Color of skin palette of Capture NX2  (for the same purpose)
* Many photos portraits: young, old, women, men, black, Asian, etc.

From such knowledge, it appears that in all cases, the skin:
* Is in the red area, generally between 0.3 and 1.2 radians and this area is flat.
* Chromaticity is between 3 and 35 rarely 50
* The luminance may vary from almost 1 or 2 to more than 95.
There is a relationship between these three parameters

I changed the menu CDbl to better meet the wish of everyone:
1) I introduced a combobox so that the user can choose between two algorithms:
* Fine: it uses already present algorithm, which target the skin closely and thus prevents
interaction with the rest of the image.
* Large : the algorithm is less fine and takes into account only the hue and chroma
(higher)

2) I introduced a Hue (skin) control - using the same slider that for "sharpening threshold"
(a traditionnal flat curve is unsuitable)
* the upper part show the choice for main hue (flat between 0.25 to 1.2 radians)
* the lower part show the amplitude of transition area (default : -0.05 to 1.7 radians)

You can slightly acts on the high and low values to better focus the image, compromise
between artifacts and image area impacted by changes.

If there are still artifacts is most likely the white balance is bad.

In some very rare cases, there may be artifacts that can only be solved by reducing
CdBL.

The solution, but also require an algorithm "hue" is to have a U-point allow the geographical
correction !!

Reported by jdesmis on 2014-02-02 07:23:50

---

• Attachment: issue2134-8.patch

[Beep6581]

Hi Jacques,

I've applied your latest patch to TIP Default, but the build crash:

/home/jcf/Developpement/workspaceCPP1/rawtherapee-default1/rtengine/dirpyr_equalizer.cc:475:85:
error: no matching function for call to ‘rtengine::Color::gamutLchonly(float&, float&,
float&, float&, float&, float&, double [3][3], bool&, float, float)’

On a side note, have you seen and tested the pipette branch?

Reported by natureh.510 on 2014-02-02 11:50:09

[Beep6581]

Hello Hombre

I don't understand !

* Hg update -C
* hg pull
* hg update
* hg import issue2134-8.patch --no-commit

Compile without any problem
Run without any problem including "Lab gamut control" that calls the function "gamutlchonly"

Yes I have tested the "pipette" (two days ago), this is a very good step forward, but
which in this case (skin CbDL) is of limited use.

When is the U-point or equivalent? I know I am ambitious, but the progress made ​​by
the pipette is notable that the U-point will be decisive.

:)

Reported by jdesmis on 2014-02-02 12:07:40

[Beep6581]

Perhaps with this change ?

Reported by jdesmis on 2014-02-02 12:30:45

---

• Attachment: issue2134-9.patch

[Beep6581]

Works well for me, thank you jacques!
Your information on skin tones is very interesting, I wasn't aware of it.

The tooltip for the new threshold adjuster is not clear to me. Could you link to a
chart which would show what sort of skin color x radians is, or that would help me
map the numerical parameters of this tool to some tangible reference?
If the radians value works like shifting hue on a color wheel, what value/color lies
at 0 radians - can you represent it in #hex?

Reported by entertheyoni on 2014-02-02 20:24:18

[Beep6581]

Jacques, may be it would be more helpful to use coloring of the threshold adjuster to
reflect the hue range that it covers?

Reported by michaelezra000 on 2014-02-02 22:14:56

[Beep6581]

Yes, it works now even in Debug builds, thanks.

Re #29:

I was about to ask the same thing; the background gradient is not appropriated here,
could you set a gradient with the hue range instead?

Sans aller jusqu'à modifier le fichier de traduction, pourrais-tu traduire les tooltip
en français car je ne les comprendspas bien. Je me permettrais alors de mettre à jour
aussi les versions anglaise si nécessaire.

Reported by natureh.510 on 2014-02-02 22:23:30

[Beep6581]

This patch take into account the new default commit.

#29 I don't know how to modify GUI ! Hombre it is your code ! can you help me ?

I enclose a graph representing "Lab" and "Algoritm skin"= "Large". You can see the
two  normal limits (tl=0.25 radians and tr=1.20 radians) and those for transitions
bl=-0.05 and br=1.7.
Also the chroma (in this case "Large" C<50))

To be more specific about the color of the skin, although for whites, blacks, yellows
the same hues. These white is mainly centered about 0.7 but that can range from 0.2
to 1.2 to 1.7 exceptionally, that of black around 0.5 black can range from 0 to 1,
the yellow around 1 ranging from 0.4 to 1.4 to 1.7 exceptionally.

Hence my choice which covers the majority of cases.

Les Tooltip en français avec plus d'explications :
Fine : on essaie de s'approcher au plus près des teintes de la peau - l'algorithme
"fine" prend en compte pour chaque niveau de luminance (< 10; 10 20; 20 35;35 52; 52
70;70 85; > 95) une amplitude variable selon cette luminance de teinte (hue) et de
chromaticité. L'amplitude de la teinte (hue) est bornée par par les valeurs "Top Left"
et "Top right" (par défaut tl=0.25 et tr=1.2) mais l'algorithme est plus précis et
modifie en interne pour chaque niveau de luminance les valeurs tl et tr.

Large : l'algorithme est plus grossier, il ne prend en compte que la chromaticité,
bien sûr en plus des valeurs tr et tl

Tooltip Hueskin :
La partie supérieure de la pyramide (tl, tr) correspond au maximum d'efficacité de
l'algorithme.
La partie inférieure (bl, br) correspond aux zones de transition - entre tl et bl l'action
de l'algo va en réduisant depuis son maximum à tl jusque 0 à bl (même chose pour tr
et br).
On peut ajuster finement les valeurs de tl, tr, bl, br mais avec une amplitude très
faible, de l'ordre de 0.2 radians, afin de mieux cerner les caractéristiques de la
peau de la photo en cours afin : a) réduire les artefacts; b) agir au minimum sur les
autres parties de l'image.
Si on est amené à modifier notablement les valeurs de tl,tr, bl, br et qu'il y a des
artefacts, c'est très probablement la balance des blancs qui est imparfaite.

Reported by jdesmis on 2014-02-03 08:57:18

---

• Attachment: issue2150-10.patch
• Attachment: skingrad.jpg

[Beep6581]

I have had a new function that reduce artifacts - in Lab and CIECAM.

It uses gaussian blur, and is performed just before "CbDL".

it is enabled by the checkbox "Lab gamut control" becomes "Reduce artifacts and (Lab)
gamut control.

Reported by jdesmis on 2014-02-03 12:51:05

---

• Attachment: issue2150-11.patch

[Beep6581]

Hi Jacques, the gaussian blur of the input signal seems to destroy the original image
detail. Is there any other approach for smoothing the effect in the transition areas
only. This method ultimately should be independent on the actual hue or range. I think
this is a generic problem - smoothing (gradually fading) the effect of the adjustment
only on the edges of the affected space, where "space" is in hue, chromaticity or luminosity,
etc. coordinates.

Reported by michaelezra000 on 2014-02-03 14:00:27

[Beep6581]

I voluntarily put a high value Gaussian Blur = 10
At 3..no or negligeable effect
At 6...similar to 10, but less destroy the original detail

We can not sort its effect...

By cons, it can control and find the right value:
* Either by a slider
* Either by the option file

:)

Reported by jdesmis on 2014-02-03 14:07:08

[Beep6581]

I have put in option :

CBDLArtif=4.5

Of course you can reduce or increase this value

for 1 quasi no action...
for 10 much blur

Reported by jdesmis on 2014-02-03 16:43:48

---

• Attachment: issue2150-12.patch

[Beep6581]

Thank you Jacques for that explanation.

I'm in favor of removing sliders from RT, where possible, not adding new ones. I think
Scribble called it "slider-shock" :]
1- I've never used the old "Threshold" slider in CbDL, is anyone in favor of keeping
it?

2- I've not found the "Algorithm Skin: Fine/Large" algorithm choice practically useful.
It just doesn't seem to have a significant enough influence to justify keeping it.
In my tests the "Skin Hue" selector was far more useful than the algorithm selection
(and will be even more useful when it actually shows the hues it applies to), so I'd
keep the "Skin Hue" selector and remove the "Algorithm Skin: Fine/Large" combobox.

3- Gamut control, I didn't find any practical use for it, unless I was doing something
extreme which I would not have done in real-life RT use. And even then, it can actually
make it worse:
http://i.imgur.com/oS2bzZN.jpg
http://i.imgur.com/rf0ZHPj.jpg The yellow colors of the filament are destroyed with
that option enabled. I'd suggest leaving it turned off and removing it from the interface.
--update
After more testing, I found a case where patch 11 produces artifacts which can be suppressed
with this gamut control checkbox, but patch 5 didn't produce them in the first place.
On the left is patch 5, on the right patch 11:
http://i.imgur.com/vQyq25V.jpg
http://i.imgur.com/EUv1Gft.png
http://i.imgur.com/VD1Sxwp.png
--update 2
The gamut checkbox has a bug - it affects all zoom levels.
http://i.imgur.com/S0wg4gK.png
http://i.imgur.com/kQBNVqO.jpg
I wonder if the example above where gamut control makes the image worse by decolorizing
the yellow filaments is just an effect of this bug, and not the correct working of
the tool?

Speaking of which, I always wanted the CbDL tool to work at all zoom levels :) Does
this bug mean that making it work (correctly) at all zoom levels is a simple switch
in the code? I know that this would not be fast, but could there be a button for full-image
preview? Real life example: when using the "4 (coarsest)" slider, you really need to
see the whole image to judge whether you like the effect, and this currently means
having to save it. Would be nice to have a preview of the whole image in RT without
saving!

Reported by entertheyoni on 2014-02-03 20:28:12

[Beep6581]

@ #35: this should not be in the options file because if you delete your modified options
file your PP3s become incompatible, or if you send your PP3s to a friend. I hope the
options file doesn't contain other such values which could change PP3 appearance...

Reported by entertheyoni on 2014-02-03 20:34:42

[Beep6581]

Re #31: J'aimerais pouvoir t'aider pour le dégradé, mais je ne comprends pas bien quelle
échelle tu as utilisé? Normalement, le dégradé de "Teinte" commence à Rouge, mais ton
graphique, à 0°, semble commencer à je ne sais quelle couleur. Pourrais-tu me confirmer
quelle fonction utiliser pour trouver la bonne couleur? hsv2rgb?

Reported by natureh.510 on 2014-02-03 22:07:34

[Beep6581]

"Reduce Artifacts/Gamut Control" checkbox bug (comment #36 point 3.update2) is also
present in issue2150-12.patch

Reported by entertheyoni on 2014-02-04 07:33:52

[Beep6581]

I will take into account all your comments ...
* Remove gamut control (although I think it may be useful and that there is no bug
in the algorithm), but the customer is always right.

* Review the algorithm "skin" - I have wrong by simplifying

* Remove the choice "Fine" / "Large"

Put the variable option is not final but to test and find good value ..

I will review the algorithm "Gaussian blur" to make it less aggressive for the rest
of the image.

This will take time, because this whole process is (very) complex.

Hombre :
Le graphique représente le domaine Lab, il faut ajouter un axe perpendiculaire au plan
pour représenter l'ensemble Lab - qui est quasiment utilisé partout dans RT.
L'axe horizontal correspond à "a" vert-rouge
L'axe vertical correspond à "b" jaune- bleu

Je vais faire une correspondance approximative vers HSV...et là tu pourras oeuvrer.

Remarque : on aurait pu faire comme choix pour tous les graph d'utiliser Lab plutôt
que HSV..mais maintenant c'est trop tard. Lab correspond à la perception de l'oeil,
HSV non !

Reported by jdesmis on 2014-02-04 08:23:22

[Beep6581]

Here the patch with corrections above !

I do not suppress the code (Fine / Large  or gamut) but only disabled

I think all changes are done  (well ??)

I reduct the area for hue skin (-40 210) it must be clearly sufficient even if the
WB is bad.

Hombre :
voici une correspondance entre radians et HSV

hsv: 0.75  rad: -0.9
hsv: 0.856 rad: -0.4
hsv: 0.92  rad: -0.1
hsv: 0.93  rad: 0
hsv: 0.96  rad:  0.25
hsv: 1     rad: 0.6
hsv: 0.0675 rad:1.2
hsv: 0.09  rad: 1.4
hsv: 0.17  rad: 1.7
hsv: 0.265 rad: 2.1
hsv: 0.324 rad: 2.5
J'espère que cela te seras utile pour le graph.
Merci 
:)

Reported by jdesmis on 2014-02-04 12:20:52

---

• Attachment: issue2150-13.patch

[Beep6581]

I did not have a chance to try the latest patch yet, but what do we mean by fine/large
control?

Reported by michaelezra000 on 2014-02-04 14:24:34

[Beep6581]

It was a possibility ( I just delete) between :
* Fine: very near skin (hue - chroma - luma)
* Large : more simple (only hue and chroma with enlarge limit)
:)

Reported by jdesmis on 2014-02-04 14:52:58

[Beep6581]

The same but CbDL work at all zoom levels. I hope there is no error :)

I have modified :
* dcrop.cc
* improccordinator.cc
* improcfun.cc (with all functions CIECAM)

Reported by jdesmis on 2014-02-04 17:09:47

---

• Attachment: issue2150-14.patch

[Beep6581]

Thank you Jacques. I was very excited, unfortunately the preview is very different from
the saved image, so it's not usable :(
Please see the screenshots - I set RT to resize when saving to the same size as the
preview (521x779): http://filebin.net/vyfgrso7bp

Reported by entertheyoni on 2014-02-04 18:49:06

[Beep6581]

Re #41: je m'occuperais du graph ce soir.

Reported by natureh.510 on 2014-02-04 23:24:44

[Beep6581]

Jacques, I was thinking about the generic approach to do smooth transitions.
Essentially, one needs to apply the effect to the original image using a blurred mask.

Original image = A
Image with the tool applied = B
Mask = (L(B)-L(A))/L(B)
Final image = A + Blur(Mask)*L(B)

This can be done on a whole image at a prrof of concept and then transitioned to tiled
processing. At some point we could make it a generic method, passing a pixel of A and
a small tile (size of the blur kernel) from B and let it return the final image value.

What do you think? If this makes sense, it can be used also for other tools where transitions
need to be smoothed.

Reported by michaelezra000 on 2014-02-05 01:47:52

[Beep6581]

Sorry but all this is turning around the local editing feature... And will come sooner
if development forces are affected to this rather than to make workarounds. It may
be time to learn how to team work!?

The Edit patch is processing well. Once (almost) done, the local editing patch can
be started.

Reported by natureh.510 on 2014-02-05 15:53:22

[Beep6581]

Here is the patch with the colored gradient, under your control Jacques :). I've also
"dust cleaned" it (spaces, tabs, indenting...), so please keep this version for future
modification.

And if the preview has to be seen at all zomm level, the wavelength of each level has
to be divided by the zoom factor (well, i guess so). So a "skip" parameter should be
send in the dirpyr function. Adapting the dirpyr function to this "skip" parameter
is another story...

Reported by natureh.510 on 2014-02-06 00:11:00

---

• Attachment: issue2150-15.patch

[Beep6581]

This is great!:)

Reported by michaelezra000 on 2014-02-06 03:20:53