imagemagick6 import issue

[Sean Enck]

On 2018-11-04, Sean Enck wrote:
> 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

OK, stable (6.9.7-4) works properly during import. Just a tangent (maybe?) 
but is there any chance that Qt (I don't know the kxstitch source and I'm 
basically hoping asking you, Steve, as a quicker question) changed 
something in color handling at all (e.g. in QColor?) - mainly I ask 
because I know (for example) stable Qt is ~5.7 and unstable is ~5.11 and sort 
of want to sanity check that thought. You probably have a better idea if it's 
worth looking at other dependencies as possible root causes. I'd hate for 
either of us to chase the wrong thing and/or keep partial fixing issues on 
this.

Let me know if you have any thoughts on any of that. I'll hold off on trying 
to track down various libraries and a lot of rebuilds until then :)

--Sean