Alternative to modulate command to increase Saturation

[henrywho]

Actually, I am trying to increase the saturation so "-gamma 1.5" seems more appropriate.... except that I am looking for a way not to touch the pixels with high saturation.... something like "if saturation > threshold then untouch else increase it". Looking for some simpler way other than masks, though.

BTW, it seems that increasing the "C" value in HCL colorspace changes also the "L" value in LAB colorspace. Hence, I try to "fix" it with some channel manipulation:

Code: Select all

convert.exe -respect-parentheses input.png -set colorspace SRGB
 \( -clone 0 -colorspace HCL -channel G +sigmoidal-contrast 3,66% -colorspace LAB \)
 \( -clone 0 -colorspace LAB -channel Red   -separate \)
 \( -clone 1 -colorspace LAB -channel Green -separate \)
 \( -clone 1 -colorspace LAB -channel Blue  -separate \)
 -delete 0,1 -channel RGB -combine -set colorspace LAB -colorspace sRGB fix_thru_lab_%d.png

Code: Select all

convert.exe -respect-parentheses input.png -set colorspace SRGB 
 \( -clone 0 -colorspace HCL -channel G +sigmoidal-contrast 3,66% -colorspace XYZ \)
 \( -clone 1 -colorspace XYZ -channel Red   -separate \)
 \( -clone 0 -colorspace XYZ -channel Green -separate \)
 \( -clone 1 -colorspace XYZ -channel Blue  -separate \)
 -delete 0,1 -channel RGB -combine -set colorspace XYZ -colorspace sRGB fix_thru_xyz_%d.png

... but fix_thru_lab_0.png and fix_thru_xyz_0.png differ by quite a bit especially on red patches. Are the two commands correct (and sensible)?

[fmw42]

BTW, it seems that increasing the "C" value in HCL colorspace changes also the "L" value in LAB colorspace. Hence, I try to "fix" it with some channel manipulation:

This is something that the IM developers need to reply. I really do not know if they should be independent. Perhaps you should post this on the developers or bugs forum.

I am looking for a way not to touch the pixels with high saturation.... something like "if saturation > threshold then untouch else increase it". Looking for some simpler way other than masks, though.

Without using a mask, the only thing that comes to mind now is using -fx. Or to use something like in my script, PLM (http://www.fmwconcepts.com/imagemagick/plm/index.php) , which creates a piece-wise linear transformation. That way you can adjust the values linearly between 0 and your threshold and keep the values above the threshold the same. A simple way to do that is to create two 1D gradients; one for below the threshold and one for above the threshold. Then process the first gradient to increase the values in the low range (but keep the right end of the gradient so it matches the left end of the second gradient. Then append them and apply them using -clut.

[snibgo]

@henrywho: if you want to increase saturation while leaving the L of Lab unchanged, the obvious way is to do it in Lab space. The a and b channels both record saturation as the distance from 0.5, that is a=b=0.5 (in the range 0 to 1) represents zero saturation. So apply the same "-sigmoidal-contrast" to both these channels.

[fmw42]

With regard to snibgo's last comment. See http://digital-photography-school.com/t ... -photoshop. That is the basis of my script, enhancelab. However as suggested in the reference, I keep the changes to channels a and b linear using -level. However, as long as the changes are symmetric about 0.5, you could use non-linear methods such as the suggested sigmoidal contrast. I learned later that this is sometimes called digital velvia adjustment. You can try that intereactively at http://jqmagick.imagemagick.org as digital velvia filter under the color category.

However, that still does not limit changes to low saturation values as you desired.

[anthony]

BTW, it seems that increasing the "C" value in HCL colorspace changes also the "L" value in LAB colorspace. Hence, I try to "fix" it with some channel manipulation:

This is something that the IM developers need to reply. I really do not know if they should be independent. Perhaps you should post this on the developers or bugs forum.

The L value in HCL and LAB should be identical and unchanged. Changing C or H in HCL should not effect L in LAB.. period. that is part of the definition. Basically HCL is defined as having the AB channels of LAB converted to polar coordinates using H (angle) and C (radius). If modifying H or C, modified L in conversions then 'Houston we have a problem'.

WARNING: make sure you examine value changes in LAB, any further conversion, such as to XYZ, RGB, sRGB, may cause a transfer of changes.

[anthony]

With regard to snibgo's last comment. See http://digital-photography-school.com/t ... -photoshop. That is the basis of my script, enhancelab. However as suggested in the reference, I keep the changes to channels a and b linear.

Then use -level on channels A and B, with the white and black points changing symmetrically, so that a 0.5 value remains 0.5.

You can also use other mathematical -evaluate and -function calls to modify channels.

[fmw42]

The L value in HCL and LAB should be identical and unchanged.

BTW, it seems that increasing the "C" value in HCL colorspace changes also the "L" value in LAB colorspace. Hence, I try to "fix" it with some channel manipulation:

Perhaps you should confirm this and if confirmed, post your results with an example on the bugs forum.

[anthony]

Well something is odd...

comaring the outputs of...
convert rose: -colorspace LAB txt: > t1
convert rose: -colorspace HCL txt: > t2


and I can see no channel value in one, matching the channel value in the other.
The first channel in t1 output, should be matching the third channel value in t2 output -- it doesn't
Though it does seem to have some type of correlation.

At least to my understanding of HCL!
See Wikipedia... http://en.wikipedia.org/wiki/CIELUV#Cyl ... esentation

The L channel should left AS-IS, just copied from first to third channel.

Hmmm looks like the conversion has 'gamma' effects in the L of HCL.


Posting in bugs...

[henrywho]

@henrywho: if you want to increase saturation while leaving the L of Lab unchanged, the obvious way is to do it in Lab space. The a and b channels both record saturation as the distance from 0.5, that is a=b=0.5 (in the range 0 to 1) represents zero saturation. So apply the same "-sigmoidal-contrast" to both these channels.

But I found something strange....

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel R -separate 0_%d.png

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel G -sigmoidal-contrast 9,50% \
 -channel B -sigmoidal-contrast 9,50% \
 -channel R -separate a_%d.png

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel G -sigmoidal-contrast 9,50% \
 -channel B -sigmoidal-contrast 9,50% \
 +channel \
 -colorspace sRGB -colorspace LAB -channel R -separate b_%d.png

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 \( -clone 0 -channel R -separate \) \
 \( -clone 0 -channel G -separate +channel -sigmoidal-contrast 9,50% \) \
 \( -clone 0 -channel B -separate +channel -sigmoidal-contrast 9,50% \) \
 -delete 0 +combine -set colorspace LAB \
 -colorspace sRGB -colorspace LAB -channel R -separate c_%d.png

1) 0_0.png and a_0.png are the same, as expected
2) b_0.png and c_0.png are the same, but different from 0_0.png.

I am wondering if "-sigmoidal-contrast 9,50%" is generating invalid/out-of-range values in A and B channels, which "invade" the overall luminance when converted to sRGB colorspace.

.... or I misunderstood the Imagemagick syntax and screwed them up.

(both "6.8.3-5 2013-02-24 Q16 Win32 Static" and "6.8.4-1 2013-03-25 Q16 Win64 Static" tried)

[snibgo]

I don't think "-sigmoidal-contrast" creates out-of-range values.

I haven't experimented with your commands, but I note that you are not explicitly converting back to sRGB or RGB at the end, before or after the "-separate". You are leaving IM to do whatever it wants to do. (It won't save a result as LAB colorspace, I suppose.) You might try "-colorspace sRGB" before each final "-separate".

[henrywho]

If it is a problem of "-separate", "b_0.png" should have been fine.

but "b_0.png" is wrong (in the same way) even if I put "RGB", "LUV", "HCL", etc. in place of "sRGB" in the middle.