How to divide images in Magick++ API?

[blackhaz]

Dear IM users,

Is there any way to divide images using composite function? I see there is a MultiplyCompositeOp, however there is no DivideCompositeOp. I can manually specify "using MagickCore::DivideCompositeOp;" and it looks to compile, however I suspect division is not working correctly. Is there any way around it? If fx is the only way, how can I supply two images to fx for a "u/v" division?

Thank you so much!

[anthony]

Is your version of IM new enough?

Does

Code: Select all

   convert -list compose

list it?

[fmw42]

Is your version of IM new enough?

Anthony,

I am working with this person and he is on Snow Leopard, Mac OSX 10.6.4 Q32 HDRI

Fred

[fmw42]

Withdrawn -- Accidentally double posted.

[blackhaz]

Anthony, yes, I get divide there in the output list. However I had to add:

using MagickCore::DivideCompositeOp;

into the headers, otherwise it didn't know what DivideCompositeOp is. However, it knows MultiplyCompositeOp without this line in the header.

[blackhaz]

So, I and Fred have tested the DivideCompositeOp and it seems to work exactly as the -compose divide -composite in command-line convert. Maybe somebody could spot a problem in the code below? The code is supposed to do Wiener deconvolution. I am following Fred's bash script. This is non-HDRI version. Both HDRI and non-HDRI versions do not work, producing the same result.

I am using the same filter, that is produced in my application using Magick++. Fred's bash script deconvolves input into this image, that can be considered as good result.



When I am using piece of code in Magick++ below, that follows every step of the Fred's script, it deconvolves input into this, that can be considered a bad result:



Here is the code using Magick++:

Code: Select all

  /* Wiener deconvolution, non-HDRI mode
        # get magnitude and phase FFT components of input and use transfer function to recover image
        # first line is FFT of input image and also the filter image 
        # second line is magnitude squared filter plus noise, i.e. denominator term
        # third line is magnitude times image magnitude part divided by denominator
        # fourth line deletes intermediate temps and does IFT
        # From Fred's bash script:
        convert \( $dir/tmpI.mpc -fft \) $dir/tmpF.mpc \
                \( -clone 2 -clone 2 -compose multiply -composite -evaluate add $qnoise \) \
                \( -clone 0 -clone 2 -compose multiply -composite \
                        -clone 3 +swap -compose divide -composite \) \
                -delete 0,2,3 +swap -ift -crop ${width}x${height}+0+0 +repage \
    */
    /* We assume the filter is read into Image tmpF, and tmpQ, tmpW, tmpE are temporary Image objects to hold images */ 
    /* ui->noiseSpin->value() is double and has the noise settings */ 
    /* tmpQ = (tmpF * tmpF) + noise */
    tmpQ=tmpF;
    strcpy(bufferA,"u*u+");
    sprintf(bufferB, "%f", ui->noiseSpin->value());
    strcat(bufferA,bufferB);
    tmpQ.fx(bufferA);
    /* This is a replacement of the script's second line via fx. Tested in script, fx works with u*u+noise and noise not scaled to quantum range */

    /* tmpW= (tmpI_magnitude * tmpF) / tmpQ, result stored to tmpQ */
    /* Assume input image magnitude is read into tmpW */
    tmpW.composite(tmpF,0,0,MultiplyCompositeOp);
    tmpQ.composite(tmpW,0,0,DivideCompositeOp);


    /* Inverse Fourier Trasnform */
    /* Assume input image phase is read into tmpE */
    tmpQ.inverseFourierTransform(tmpE,true);

I think I haven't missed anything and I'm still scratching my head on what goes wrong. I have tested inverseFourierTransform in Magick++ and it produces good image if I feed magnitude and phase components that are produced by the bash script. All the settings - filter and noise, are the same when I produced Jupiter images above using bash and my Magick++ app.

Thank you in advance!

[blackhaz]

Dear All,

This has been resolved. I converted images to XPMs so Qt could display them. Probably some part of the information was lost along the way (limited precision of XPM?). Without conversion everything works perfectly now and I get results identical to Fred's bash script.

Bow to ImageMagick developers!

Max

[anthony]

XPM's is a color indexed TEXT image file format and does have some limitations.
Though it is better than GIF in its color index limits, but not in compression (generally uncompressed)

It is not recommended for real life images, that is images with large numbers of colors and large dimensions.
It was designed with 'icons' in mind. That is small images of limited color for use in X window displays.

Its primary benifit is as a method of image to ascii image conversion.