Legacy ImageMagick Discussions Archive

iGaret wrote:Hmmm aren't levels different than curves?

Can I pass a polygon to levels to make it run a lookup table on it? Because that's what I need... If I needed to adjust the levels I would've used levels, but I need curves. So I use a lookup table.


Is there something I'm missing?

see my script curves below -- you provide a set of transformation points and they get splined into a smooth curve and lut created and applied using -clut.

You can also create a gradient and apply a polynomial function to it to generate your lut. You only need one row or column of gradient. See -function polynomial. http://www.imagemagick.org/Usage/transf ... polynomial

We can use a lookup table and it will speed up the -clut option significantly. Look for a patch in ImageMagick-6.6.8-7 Beta by sometime tomorrow.

-clut handlin is slow from some reason.

However there is more to it than that. the interpolation handling provided by the use of a CLUT image is very important! Basically it smooths very small CLUT's, and can be controlled by the -interpolate setting.

Another alturnative that may be faster is to do you 'slow CLUT' process against a HALD image.
that HALD image can then be applied to whatever image you like.
http://www.imagemagick.org/Usage/color_mods/#hald-clut

The only drawback is HALD image do not handle transparency, but then you don't seem to be doing transparency.

The hald image is relativity smaller, and presumably access in a much lower way so may be faster

Hmmm Speed test.
Preparation (don't before hand so time is not important. The image is so small that the HALD generation took only 0.325 seconds!

Now the main test apply the hald to a large image (no save) time to process ... Arrrgghhhhh... 30 seconds!!!! that is dreadful! (Dual Core 2.8GHz Pentiums)

Your command:

• convert -size 3184x2120 xc: hald.png -hald-clut null:

ran in 3 seconds on our modern I7 processor.

Previously
convert -size 3184x2120 xc: \
\( -size 256x256 xc:black -fill white -draw "polygon 0,0 0,21 139,136 255,243 255,0" \
-crop 256x255+0+1 +repage -scale 256x1! -channel blue \) -clut \
null:

took 9 seconds (dual-core 2.8Mhz pentium)

Now with changes made by Cristy, to pre-read and cache the CLUT image into a table.
It now takes... 0.32 seconds to complete --- a fantastic improvement.

EXPERT EXPLANATION...

The actual cause of this problem is that the CLUT operator will look up the pixels along the diagonal of the CLUT image. This was so that he CLUT image could be either a row, or column of pixel values and things would come out correctly without needing to specify if the CLUT image was a row or column CLUT image.

Their was not built in function to extract just diagonal pixels into a cache lookup array. So each value was lookup up, as needed one pixel at a time -- that was slow. If the lookup was an actual row or column of the CLUT image a cached lookup could be performed ONCE, and a fast result was possible.

Now the diagonal is looked up, and cached first, and the slowness removed.

It is obvious now that Christ has fixed this, but not so obvious before hand. Big thank you to Cristy for the fix.

Is -clut after the change still sensitive and run correctly according to the -interpolate setting?

fmw42 wrote:Is -clut after the change still sensitive and run correctly according to the -interpolate setting?

It is correct for interpolate in all my test.

However it is failing with handling of alpha in special cases such as coloring no-alpha grayscale with a clut containign alpha.

I have reported this and the exact reason why it is failing, as I was the one to originally debug and fix this problem last time.