imagemagick6 import issue

[Sean Enck]

On 2018-11-04, Steve Allewell wrote:
> On 03/11/2018 17:00, Sean Enck wrote:
> > On 2018-11-03, Steve Allewell wrote:
> >> On 02/11/2018 23:51, Sean Enck wrote:
> >>> I was using kxstitch compiled against imagemagick V6 and it appears that 
> >>> image import doesn't work properly (running against the git head as 
> >>> we've already fixed the last issue). In V6 of imagemagick the import 
> >>> produces a completely black image. I bisected and was able to get to 
> >>> 295773f44bfda1227d85edf065a8de14dc889159 as the commit that caused the 
> >>> actual regression. The gist below is a partial revert where I was able 
> >>> to successfully import an image with colors (aka not all black).
> >>>
> >>> Again this only against imagemagick V6.
> >>>
> >>> Patch: https://gist.github.com/enckse/de74000c2fc41c3ceb90c97fa9693250
> >>>
> >>> --Sean
> >>>
> >> Hi Sean
> >>
> >> Thanks for that.
> >>
> >> The number of problems I have had keeping up with the changes in the Magick++ API, I have started looking at my own colour
> >> reduction/mapping code to try and get away from using it.
> >>
> >> I'm not sure why the pixelColor function doesn't work in V6.  It is available in the API and it should return the same value as in V7.
> >>
> >> The pixelColor code essentially does the same as your patch assuming the image is a DirectClass.
> >> The PseudoClass is for indexed colour palettes.
> >> -----------------------------
> >> Magick::Color Magick::Image::pixelColor(const ssize_t x_, const ssize_t y_) const
> >> {
> >>   ClassType
> >>     storage_class;
> >>
> >>   storage_class=classType();
> >>   if (storage_class == DirectClass)
> >>     {
> >>       const PixelPacket
> >>         *pixel;
> >>
> >>       pixel=getConstPixels(x_,y_,1,1);
> >>       if (pixel)
> >>         return(Color(*pixel));
> >>     }
> >>   else if (storage_class == PseudoClass)
> >>     {
> >>       const IndexPacket
> >>         *indexes;
> >>
> >>       indexes=getConstIndexes();
> >>       if(indexes)
> >>         return(colorMap((size_t) *indexes));
> >>     }
> >>
> >>   return(Color()); // invalid
> >> }
> >> -------------------------------
> >>
> >> I am going to build a virtual machine and try different versions of ImageMagick to see if I can resolve this.
> >>
> >> Regards
> >>
> >> Steve
> >>
> > 
> > Yeah I've definitely noticed the sprinkled "#if"'s around imagemagick 
> > items and assumed the API changes have been a pain. I figured you would 
> > probably have a better approach but I figured I could at least figure 
> > out some form of resolution to help point you in a direction and utilize 
> > the functionality if needed :)
> > 
> > Let me know if I can be of any assistance (I'm pretty much on v6 for a 
> > while)
> > 
> > --Sean
> > 
> Hi Sean
> 
> This doesn't appear to be a clear difference between V6 and V7.  I have installed OpenSuSE 42.2 with Magick++ 6.8.8.  With the
> current code in git HEAD, importing images with and without transparency works as expected.
> 
> Which version of ImageMagick do you have which fails?  This will give me a bounding range of versions that I can check.
> 
> Thanks
> 
> Steve

Hhmmm...running debian (unstable) in this case: 6.9.10-14

I can try running in stable (against kxstitch head) which is 6.9.7-4 and 
confirm if the issue is still around (and help bound for you further) sometime 
later today/tomorrow (I'll have to rebuild kxstitch 2.1.1 which isn't hard I 
just have to setup the chroot/environment for it). There are _so many_ 
releases that hopefully that can either get us between you (6.8.8) and stable 
or between stable (6.9.7-4) and unstable (6.9.10-14)

I'll investigate on this end and let you know (I swear I saw this 
working with v6 a while ago on archlinux which would've been recent-ish 
as well at the time).

--Sean