How use -clut option

[guillaumech]

Hi Anthony, thank you so much for your help, fmw42 & snibgo also!

Just before you talk to me to try autotrace, potrace and magnify, I had tried
So, I showing my results :

Always with this main file :



Method

Code: Select all

convert main3.png +repage autotraceIM.svg;

File => http://nauton.espace-meteo.com/autotraceIM.svg

Method

Code: Select all

potrace ./processing/map/main3.pgm ./processing/map/potrace.eps;

File => http://nauton.espace-meteo.com/potrace.eps

Method

Code: Select all

convert main3.png +repage -filter Spline -resize 2080x1430 Spline.png;convert Spline.png autotraceIMSpline.svg;

File => http://nauton.espace-meteo.com/autotraceIMSpline.svg

Method

Code: Select all

convert main3.png +repage -filter Box -resize 2080x1430 Box.png;convert Box.png autotraceIMBox.svg;

File => http://nauton.espace-meteo.com/autotraceIMBox.svg

Method

Code: Select all

convert main3.png -magnify Magnify.png;convert main3.png -magnify Magnify.png; ...

File => http://nauton.espace-meteo.com/Magnify.png

Method

Code: Select all

convert Magnify.png autotraceIMMagnify.svg;

File => http://nauton.espace-meteo.com/autotraceIMMagnify.svg

I haven't yet try to colorize with clut option. All results are not perfect. Maybe I take the wrong way?

[fmw42]

I think you should resize the potrace.eps image and save as png. That way you do not get blocky results or new grayshades as you would with -scael or -resize.

Code: Select all

convert -density XX potrace.eps result.png

where XX is the density needed to get the size you want

density=72*outwidth/inwidth

[guillaumech]

Potrace loses values...
Compare potrace.eps and main3.png

[guillaumech]

No more solution?

Thank you very much for all help.

[guillaumech]

Hello,

Eternal question, why clut option does'nt work?
I've 13 colors :

• c1 = 0
  c2 = c1 + 17
  c3 = c2 + 17
  ...
  c13 = 255

With this clut gradiant :

Code: Select all

convert -size 13x1 xc: -draw '
      fill #FFFFFF rectangle    0,0 13,1
      fill #6EA1FF rectangle    1,0 13,1
      fill #3770DF rectangle    2,0 13,1
      fill #0040BF rectangle    3,0 13,1
      fill #FC85F8 rectangle    4,0 13,1
      fill #FD42F7 rectangle    5,0 13,1
      fill #FF00F7 rectangle    6,0 13,1
      fill #FA8484 rectangle    7,0 13,1
      fill #FC4242 rectangle    8,0 13,1
      fill #FF0000 rectangle    9,0 13,1
      fill #FAAF84 rectangle    10,0 13,1
      fill #FC9142 rectangle    11,0 13,1
      fill #FF7300 rectangle    12,0 13,1' grad.png

So, 1 level per colors no? I've 13 colors, gradiant has 13 levels.

With this image
I obtain this image with clut option :

Code: Select all

convert 01.png grad.png -interpolate Integer -clut 01Clut.png;

Where is my first value/color??? The 17 value...
I don't understand clut option. Is it a bug?

With -auto-level it's better, I've my first value (I don't understand why but I've the first value), but I haven't colors of my gradiant... (for exemple with fifth color, the first purple)

And with -interpolate nearestneighbor it's the same, I lose the first purple...


Thx.

[snibgo]

Clut has no bugs, as far as I know.

Perhaps ...

Code: Select all

convert in1.png grad.png -interpolate NearestNeighbor -clut out1.png

... does what you want. (As fmw42 suggested on page 1.)

If this doesn't do what you want, please say what you want.

[guillaumech]

Hi snibgo!

Read back my previous post, I tried with NearestNeighbor
I want... exact same color from my gradient.

See:



Why the value 4 and 5 are same? whereas on the black&white image not?
My gradient is linear...

I use this code

Code: Select all

convert 1.png -auto-level grad.png -interpolate nearestneighbor -clut out.png;

[snibgo]

You edited your reply while I wrote mine.

When I run the command on your latest grey file, colours 4 and 5 are different, and the correct colours are chosen from the clut file.

[guillaumech]

Which version?

[snibgo]

I'm on v6.8.8-7 on Windows 8.1.

[guillaumech]

Version: ImageMagick 6.8.8-10 Q16 x86_64 2014-04-10 on Linux Debian

So, with this main file:
With this gradient :

Code: Select all

convert -size 13x1 xc: -draw '
      fill #FFFFFF rectangle    0,0 13,1
      fill #6EA1FF rectangle    1,0 13,1
      fill #3770DF rectangle    2,0 13,1
      fill #0040BF rectangle    3,0 13,1
      fill #FC85F8 rectangle    4,0 13,1
      fill #FD42F7 rectangle    5,0 13,1
      fill #FF00F7 rectangle    6,0 13,1
      fill #FA8484 rectangle    7,0 13,1
      fill #FC4242 rectangle    8,0 13,1
      fill #FF0000 rectangle    9,0 13,1
      fill #FAAF84 rectangle    10,0 13,1
      fill #FC9142 rectangle    11,0 13,1
      fill #FF7300 rectangle    12,0 13,1' grad.png

And with this code

Code: Select all

convert 1.png -auto-level grad.png -interpolate nearestneighbor -clut out.png;

You obtain an image with value 4 and 5 are different?
How is it possible??
Can you show me your out image?

Okay, now it's work! I had another version before, I just installed this new version, maybe...

[snibgo]

Here it is:

[guillaumech]

Alright,
Thank you very much snibgo. It's work now! I don't know why...

[anthony]

While the OP's request has been answered, here is a repeat of an answer I supplied privately on using CLUT.

I am repeating it here as a way to make the information public, and to promote possible discussion. Especially as it indicates that some aspects of CLUT operations have not been explored (-virtual-pixel effects on CLUT results)

All the examples for the testing CLUT handling is shown in http://www.imagemagick.org/Usage/color_mods/#clut

This shows how the range of values is scale and then used as a diagonal position across the CLUT image for the lookup. For a single row or column of pixels that naturally equates to being equivalent to the longest dimension.

For example 13 colors -> image that is 13 long with values going from 0 to 12

A color value of 50% grey -> 0.5 whcih is then scaled by 13 -> 7.5 or the very middle of the image in 'image coordinates' (as opposed to pixel or drawing coordinates).

The position for lookup in the CLUT image is naturally a floating point number, but colors only exist in integer units., which is why the -interpolate setting is used to determine that actual color used.

Integer mean always round down the position to the lower integer value, so 7.5 -. 7.0 or the pixel color at pixel number 7 (the 8th color in the list of colors creating the image)

Nearest neighbour rounds the value to the nearest integer. which for 7.5 would be 8, and result in the color of the 8th pixel in the clut image or 9th color in the color table used to create that image.

Note interpolated lookup is also the lookup used by -fx equations, and in fact -clut lookup were originally developed from -fx equations.

That is the color in source image used to lookup colors from the second image by position within that image.


WARNING: Interpolated color lookup can also involve virtual pixels! The default setting of virtual pixels (the pixels that surround the image proper when doing actual lookups) defaults to 'edge', which basically removes its effect for more interpolation methods, though it does have an effect for a 'cubic' or 'spline' interpolation, in the gradient curves generated.

Setting -virtual-pixel to something other than 'edge' however can have very strange effects on colors looked up from a clut image, especially single row and column clut images! For example I theorize that using -virtual-pixel white, using one of the larger 16 pixel interpolation methods, will 'tint' the color lookup at both ends of the CLUT image, specifically single row-column CLUT's.

Also as the color lookup is restricted to a diagonal across the CLUT image (which allows IM to use either a row or column CLUT image without change), means in a image that isn't using a single row or column of colors, you can get non-uniform color lookups as the diagonal crosses different pixel areas. This probably can be seen best using integer lookups.


See Interpolation
http://www.imagemagick.org/Usage/misc/#interpolate

And Virtual Pixels
http://www.imagemagick.org/Usage/misc/#virtual-pixel

ADDUNDUM: From my memory I can remember tweeking the calculated lookup position in a 'integer' interpolated CLUT. so it is scaled by image size +1. That is so the resulting floating point number can in fact see the right/bottom most pixel color. It is a sort of unpublished 'tweek' of the code, and only used for 'integer' interpolated CLUT lookup.

Without doing this, that right/bottom most color would never be looked up by a CLUT, except for a pure 'white' lookup value. The smallest off-white value in the lookup, and you would get the second highest color, whcih is not generally what people expect.

Basically at the time I worked on that code, I had not yet worked on image distortions and as such did not yet have a understanding of the effects of pixel coordinates verses image coordinates for color lookup. Essentually a understanding that 'pixels have area'. Because of this lack of understanding at that time, the code may not be quite right, and should be checked and possibly adjusted to do the scaling math with a half pixel offset, just as distorts do.

See Distortion Verbose Output, and this notes about the 1/2 pixel offsets in the FX equivelent distortion
http://www.imagemagick.org/Usage/distor ... rt_verbose