This is a clone of https://bugs.gentoo.org/show_bug.cgi?id=466798
Quoting from the bug report:
Saving a file into png format from showfoto (part of digikam) fails with error "libpng error: profile 'icc': 1B0Ah: invalid length"
It was working with libpng:1.5
replacing
/usr/share/apps/libkdcraw/profiles/srgb-d65.icm
with
/usr/share/apps/libkdcraw/profiles/srgb.icm
work.
Both files are from kde-base/libkdcraw-4.10.2
the size seem to be correctly reported (3rd and 4th byte in file)
0x1B0A == 6922
-rw-r--r-- 1 root root 6922 1 mar 08.01 /usr/share/apps/libkdcraw/profiles/srgb-d65.icm
iccexamin (and opening the files with an hex editor) seem to confirm both profiles are ok, so not a bug for libkdcraw.
the bug seem to be in libpng being overzealous, see the following function from png.c
png_icc_check_length(png_const_structrp png_ptr, png_colorspacerp colorspace,
png_const_charp name, png_uint_32 profile_length)
{
if (profile_length < 132)
return png_icc_profile_error(png_ptr, colorspace, name, profile_length,
"too short");
if (profile_length & 3)
return png_icc_profile_error(png_ptr, colorspace, name, profile_length,
"invalid length");
return 1;
}
Here's the file /usr/share/apps/libkdcraw/profiles/srgb-d65.icm
--- Comment #7 from Francesco Riosa francesco+gentoo_bugzilla@pnpitalia.it ---
for completeness:
Table 17 — Profile header fields of section 7.2 in
http://www.color.org/specification/ICC1v43_2010-12.pdf
describes the first 128 bytes of an icc file
https://bugs.gentoo.org/show_bug.cgi?id=466798#c8
Following this ^, feeel free to close this report as invalid. (I have no idea how to do that even though I submitted it.)
The ICC spec has a history. Spec ICC.1:2001-04 says nothing about a requirement of byte padding as is checked in the mentioned libpng code: "if (profile_length & 3)". Many widely distributed profiles originate from those version ICC 2.x times. See: http://www.color.org/ICC_Minor_Revision_for_Web.pdf Section 6.1.1.
So a argument of invalid profiles is not correct. libpng would have to check for (icc_version >= 4 && profile_length &3) to detect a real invalid profile.
We have many projects in Linux land which still distribute those old profiles for reasons of steadiness and because they are widely used already. Changing those profiles here and then will increase computational costs and decrease precission, because of unnecessary conversions.
Please reopen this bug.
I made the suggested fix to the libpng16 branch of the GIT repository. Thanks.
Attached is a patch to fix writing as well. It applies to the libpng16 branch. Thanks.
Writing patch applied to the GIT libpng16 branch. Thanks.
Attached is another profile that libpng-1.6.10 objects to. It is a grayscale V2 profile, with a gamma=2.2 curve. Libpng thinks it's an sRGB profile that has been edited, because the MD5 is zero (like all V2 profiles). I have pushed a fix for this problem (which was due to a misplaced closing "}") to the GIT repository for libpng16 (will be libpng-1.6.11beta05).
The GrayGamma22.icm profile looks fine in oyranos-profile and iccexamin tools. The MD5 based ICC hash sum is optional for v2 profiles.
Oyranos places a missing hash into all profiles automatically, as it can not affect the ICC hash itself and has no known side effects during colour processing.
Fixed in libpng-1.6.11, thanks.