-clut for animated images..

[dognose]

I use the -clut option a lot for recoloring images..

convert animated.gif colors.png -clut outimage.gif

however, it doesn't well with animated images... besides removing the animation, it doesn't properly color the image, and I end up with a negative image instead.

Is there any way around this, besides processing each frame of the animation individually in separate commands?

[anthony]

Until we convert -clut into a type of 'composition' method. there is not easy simple way.

The only suggestion is to create a shell loop around the image, so you can process them individually

Question, By 'animation' could you mean processing a VERY long video sequence?

I created technique of pipeline processing a stream of multiple images using perl to read and proces one image from the pipeline at a time. Specifically so that you don't run out of memory by trying to read ALL the images in at the same time.

See the discussion... "reading multiple images over standard input"
viewtopic.php?f=2&t=18320

You can use that technique for
convert animation.gif ppm:- | pnmnoraw | .... | convert - new_animation.gif

This however is no good for GIF animations, as that can not be pipelined (well I know of no tool that can convert GIF in a pipeline sense!) But you can still use the same technique.

[anthony]

I have converted that ascii-PPM image pipeline program into a script, "process_ppm_pipeline"
http://www.imagemagick.org/Usage/script ... m_pipeline

As such you can do you CLUT of images like this...

Code: Select all

convert animation.gif  -coalesce -compress none ppm:- | 
   process_ppm_pipeline   clut.png  -clut  |
   convert -  -set delay 10 -loop 0 -layers optimize animation_recolored.gif

Note the "process_ppm_pipeline" script takes normal "convert" arguments, but you exclude the input read (assume ONE image is already in read in) and the output image filename. You just give the options you want to use to convert the pipeline, one PPM image at a time.

[dognose]

Oh, ok, the hard way, but already scripted. ..

http://www.imagemagick.org/Usage/script ... m_pipeline
404 Not Found

Anyone still have a copy?

[anthony]

Oh, ok, the hard way, but already scripted. ..

http://www.imagemagick.org/Usage/script ... m_pipeline
404 Not Found

Anyone still have a copy?

The script is present and the link does work!

It just took a little time for the web site to recieve the script which I build from the perl I previously developed on the other discussion. Basically put the perl in a file, map command line arguments to the called convert command.

It could do with a bit more work as it currently buffers one image in memory before calling the internal "convert" part of the pipeline. It could for example start the convert command as soon as it sees the start of the image, then close it when it sees the start of the next image without buffering the whole image, just one line (row) of ascii PPM text.

Of course with some extra smarts it could actually read the PPM header and then read and transfer the exact amount of RAW (binary) PPM data. In that case it will know exactly when the image ends and the next (should begin).


The IDEAL method would be to use mogrify with some smarts to only read ONE PbmPlus image in from a pipeline at a time, without closing the input pipeline, so when ready it can read the next one.

However knowing the source of mogrify, this may NOT fit with the implementation as it currently stands. That is: read first image argument found, apply all command line arguments that is not to do with reading an image, write result, then loop to read next image found on command line. It would need to be modified to handle multiple 'single' images from one image read argument. Coders would also need to modify to return one image at a time too.

My solution was a wrapper work-around, and will actually allow full "convert" style arguments.

In the future I hope to create a morgify that can handle "convert" type arguments, though that will need some sort of separation on 'arguments to loop on, including secondary reads', and the 'images to read one at a time'.

Sorry this is an area I have been looking at with a view to IM v7 improvements. EG: read image operations from files, pipelines and sockets, with image processing operations being REALLY applied as seen.