Regression: Magick++ truncating multi-page images/animated GIFs

[tc33]

Using version 6.9.3-8. See Magick++ / image.cpp, line 5116:

Code: Select all

void Magick::Image::read(MagickCore::Image *image,
  MagickCore::ExceptionInfo *exceptionInfo)
{
  // Ensure that multiple image frames were not read.
  if (image != (MagickCore::Image *) NULL &&
      image->next != (MagickCore::Image *) NULL)
    {
      MagickCore::Image
        *next;

      // Destroy any extra image frames
      next=image->next;
      image->next=(MagickCore::Image *) NULL;
      next->previous=(MagickCore::Image *) NULL;
      DestroyImageList(next);
    }
    
    ...

When reading an image with multiple images, like an animated GIF, the additional images are being removed from the image pointer. I would imagine the same issue occurs on multi page TIFFs, PDFs, etc. I need to programmatically determine if an image is an animated GIF or not, and I did so by querying the MagickCore::Image->next pointer.

Prior versions of IM/Magick++ did not do this and worked properly; circa IM 6.6.xxx IIRC.

Does Magick++ no longer support multi-framed images?

[dlemstra]

I am not sure when this was changed but you should use 'readImages' to read multiple frames from an image.

[tc33]

Hi dlemstra thanks for the response.

I tried using ReadImages along with the Magick++ image interface, and magickcore freezes. Same behavior with 3 different input files. I think I've discovered a separate bug deeper in the core; I'll have to report that separately. My psuedocode is roughly:
Read image file to uchar*
Uchar* to magick++ blob
Construct Magick++ image using that blob --> truncation of multi images happens here
ReadImages( img.constImageInfo() ) --> MagickCore hangs here

I also tried using ReadImage() instead of ReadImages() and it hangs in the same spot.

So, unfortunately, I'm back to where I started. I'd really hate to have to duplicate parts of Magick++ in order to work around this limitation. In its current state, Magick++ will corrupt any multi-frame images. For example, this code corrupts an animated gif:

Code: Select all

auto img = Magick::Image( "path/to/myfile.gif" );
img.write( "path/to/myfile2.gif" );  //  corruption:  this only writes the first frame!

This is a serious limitation of Magick++. I guess i'm just trying to figure out why this change was introduced recently, and then determine if I can continue to use Magick++ in its current form. I could look into submitting a pull request if you are open to the idea restoring this functionality into Magick++, but I won't bother if you are moving away from this capability going forward. I just hate the idea of writing my own wrapper around MagickCore, since I thought that was the intent of Magick++ from the beginning.

Thoughts? Thanks again!

[dlemstra]

Are you using readImages from STL.h or are you calling ReadImages from MagickCore? You should be using the first one. And we won't change Magick++ so that an Image can contain multiple images.

[tc33]

Yes I was using the one from MagickCore, I wasn't familiar with the contents of STL.h. That looks like what I need.

So if I'm understanding Magick++ correctly, I want to use a container of Magick::Image to represent multi-framed images, as a single instance of Magick::Image only represents a single frame?

Thanks for pointing me in the right direction

[dlemstra]

You are understanding Magick++ correctly

[tc33]

Better late than never! Thanks for your help