test_tiff_rgb12 and test_tiff_rgb14 fail with ImageMagick 6.9.10 #119
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
I found out why some of the tests fail on Travis. When you check for the version, e.g. here, you enter a different branch of the if.
Ubuntu Focal's (ImageMagick 6.9.10-23) doesn't have that version attribute which was added in 6.9.11 (the version Bullseye has).
If you remove the if for both PNG TIFF tests, they should pass on both Ubuntu Focal and Debian Bullseye.
test_tiff_rgb12 and test_tiff_rgb14 fails with ImageMagick 6.9.10to test_tiff_rgb12 and test_tiff_rgb14 fail with ImageMagick 6.9.10Thanks for looking into this! But I don't think I follow. I can confirm that on Debian Bullseye, the
else
clause is the right one, the one which says:But for for older imagemagick versions, meaning those less than 1.0 or those without the
version
information, the value14
should be correct. That's why I useidentify[0].get()
and default to"0"
in case the version attribute is missing.Are you saying that Ubuntu Focal also needs the value
16
? What value is needed for ImageMagick 7?Yes, I think so. Throughout my tests, I saw that all versions (Gentoo or Arch with IM 7, Focal and Buster with IM 6, be it before or after the JSON version attribute appeared) seem to need
16
. The Travis build shows what happens on Focal:https://app.travis-ci.com/github/josch/img2pdf/jobs/533073335
I see that when that version 1.0 attribute was added, a typo was fixed in "endianness" but I didn't see any mention of bit depth in the changelog.
On a slightly different topic, I have also noticed that a lot of tests (not necessarily these two) dislike ImageMagick built with
--with-quantum-depth=8
or 32 instead of 16, I stumbled on this today via https://bugs.gentoo.org/809593 (build log here).Alright, if you open a merge request, I'll make the change accordingly and drop the if.
From reading the log, could it be that the
depth
attribute actually reflects the quantum-depth? I don't see this explained in the imagemagick docs, but if so, then we should never check thedepth
attribute anyways but only look atbaseDepth
.It's great that you are testing img2pdf on gentoo. The disadvantage of binary distributions like Debian and Ubuntu is, that my code is never run with its dependencies built with different configure settings.
We disabled these two tests when we started running the test suite for img2pdf in 2022/01.
Maybe this is just a bug in my (old) imagemagick version but with imagemagick 6.9.11.60 the depth attribute for 12 or 14 bit tiff files (wrongly) reports as 16. Maybe it makes sense to just relax this test like this:
EDIT
Nah, lets just drop this test because we already check
baseDepth
.@sbraz, @hexa could one of you please verify whether the patch in my last message fixes this issue, thanks!
Works for us. Thanks!