[Pkg-gmagick-im-team] Bug#1105051: imagemagick breaks xplanet autopkgtest: test_compare_images() returned non-zero return code

[Jochen Sprickerhof]

Hi Bastien,

* Bastien Roucaries <rouca at debian.org> [2025-05-16 14:53]:
>Le vendredi 16 mai 2025, 13:31:55 heure d’été d’Europe centrale Jochen
>Sprickerhof a écrit :
>> Hi,
>>
>> * Paul Gevers <elbrus at debian.org> [2025-05-10 14:24]:
>> >With a recent upload of imagemagick the autopkgtest of xplanet fails
>> >in testing when that autopkgtest is run with the binary packages of
>> >imagemagick from unstable. It passes when run with only packages from
>> >
>> >testing. In tabular form:
>> >                       pass            fail
>> >
>> >imagemagick            from testing    8:7.1.1.47+dfsg1-1
>> >xplanet                from testing    1.3.1-3
>> >all others             from testing    from testing
>> >
>> >I copied some of the output at the bottom of this report.
>> >
>> >Currently this regression is blocking the migration of imagemagick to
>> >testing [1]. Due to the nature of this issue, I filed this bug report
>> >against both packages. Can you please investigate the situation and
>> >reassign the bug to the right package?
>>
>> There are multiple problems:
>>
>> 1. imagemagick changed the output of compare in 7.1.1-44 (d85a7583f)
>>     from some number <= 1 with 1 meaning the images are the same two two
>>     numbers where the first is the distortion and the second one is the
>>     old percentage in parenthesis. This breaks the test code in
>>
>> https://sources.debian.org/src/xplanet/1.3.1-3/debian/tests/compare-create-> image/#L32 I assume that the new format will be kept so xplanet should adopt
>> the logic. Maybe something like:
>>
>>     result_jpg="$( compare -metric ncc
>> $AUTOPKGTEST_TMP/expected/$filename.jpeg $AUTOPKGTEST_TMP/$filename.jpeg
>> $AUTOPKGTEST_TMP/diff.jpg 2>&1 | sed 's/.*(\(.*\))/\1/' )"
>>
>> 2. imagemagick in stable returns values below 0 for similar but
>>     different images. I did not check if this was different in older
>>     versions but I would expect so, given that the autopkgtest code
>>     checks the value for >0.99. This has been corrected by multiple
>>     patches in imagemagick git main.
>>
>> 3. imagemagick in unstable has a bug resulting in the same picture
>>     getting a percentage of 0 and different images a value of > 1. This
>>     has also been corrected in imagemagick git main (912b6a838).
>>
>> 4. The results of earth_markers.* in the compare-create-image
>>     autopkgtest improved (not sure due to what) so the files in
>>     debian/tests/expected/earth_markers.* need to be replaced.
>>
>> I think we have to accept that the output of compare is not stable and
>> adopt xplanet. I see two options what to do:
>>
>> a. Adopt the xplanet to cope with any output of compare. This could be
>>     either by just using the return value, hoping that the output on
>>     different architectures is stable nowadays (I did not test this) or
>>     by adding logic that only compares the number in case the return
>>     value is not 0 (perfect match) and then try to interpret the
>>     number(s).
>>
>> b. Apply the imagemagick patches from git main and use the call from 1.
>>     above.4
>
>go b before hard freeze. Can I have git commit ?

See all those patches for metrics here:

https://github.com/ImageMagick/ImageMagick/commits/main/MagickCore/compare.c

Not sure which ones to select (except 912b6a838).

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gmagick-im-team/attachments/20250516/e042d9ad/attachment-0001.sig>