imagemagick6 import issue

[Steve Allewell]

On 04/11/2018 22:28, Sean Enck wrote:
> 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
> 
Thanks for the efforts you are putting in.

OpenSuSE 42.2 runs Qt 5.6 and Tumbleweed (which I normally develop in) runs 5.11.  Qt is pretty stable from an API point of view
so I'm tending not to point the finger there.  I suspect that it will be whatever is coming back as the transparency value of the
colours coming from ImageMagick, but I'm not sure why HEAD doesn't work and your patch does when they do basically the same thing.

I will start looking at the versions of ImageMagick from the working to not working and see what I find.

Thanks again

Steve