PNG test image with broken profile

Confirmed. Does RawTherapee show the same behaviour for tiff files?

No, for the corresponding TIFF and JPG files, RT correctly shows “red” as red.

Darktable gets this one right.

RawTherapee and Geeqie both (or libpng?) fail at reading the embedded ICC profile in that PNG file.

libpng warning: iCCP: Not recognizing known sRGB profile that has been edited

Same for ImageMagick:

convert: Not recognizing known sRGB profile that has been edited `foo.png’ @ warning/png.c/MagickPNGWarningHandler/1665.

However, if I extract the ICC profile and set it manually in RT, it looks as it should.

It looks like the problem comes from two areas:

  1. libpng-1.6.* is more stringent about checking ICC profiles than previous versions, so you might not experience this problem if using libpng <1.6.
  2. The libpng warning is treated as an error.

Further discussion specifically related to RawTherapee to be handled here:
Custom ICC not read from PNG · Issue #4260 · Beep6581/RawTherapee · GitHub

It seems that this test image is based upon an old and broken profile, so having a program not use it is not necessarily a bad thing.

http://www.libpng.org/pub/png/libpng-manual.txt

Error detection in some chunks has improved; in particular the iCCP chunk
reader now does pretty complete validation of the basic format. Some bad
profiles that were previously accepted are now accepted with a warning or
rejected, depending upon the png_set_benign_errors() setting, in particular
the very old broken Microsoft/HP 3144-byte sRGB profile. Starting with
libpng-1.6.11, recognizing and checking sRGB profiles can be avoided by
means of

#if defined(PNG_SKIP_sRGB_CHECK_PROFILE) && \
    defined(PNG_SET_OPTION_SUPPORTED)
   png_set_option(png_ptr, PNG_SKIP_sRGB_CHECK_PROFILE,
       PNG_OPTION_ON);
#endif

It’s not a good idea to do this if you are using the “simplified API”,
which needs to be able to recognize sRGB profiles conveyed via the iCCP
chunk.

The PNG spec requirement that only grayscale profiles may appear in images
with color type 0 or 4 and that even if the image only contains gray pixels,
only RGB profiles may appear in images with color type 2, 3, or 6, is now
enforced. The sRGB chunk is allowed to appear in images with any color type
and is interpreted by libpng to convey a one-tracer-curve gray profile or a
three-tracer-curve RGB profile as appropriate.

I have no problem with software that rejects my ICC profile as “bad”. I’m not sure I like software to silently ignore it. And accepting it in some images (TIFF, JPEG) while ignoring it in others (PNG) seems a bit naff, though I realise this is because of the underlying libraries having different acceptance criteria.

It might help if I explained how I made the ICC profile. Sadly I’ve forgotten. I made redblue.png in 2013, from snibgoGBR.icc which I made in 2010. snibgoGBR.icc is 3144 bytes long, and I made it by hacking some other profile.

I intended the profile as a simple, easy-to-see test for whether software respects profiles. But if my profile is bad, it doesn’t test what I intended. That’s good to know, so thanks for spotting this, everyone.

I’ve uploaded the profile to …
http://snibgo.com/imforums/snibgoGBR.icc
… if anyone wants to play with it.

Libpng code has code sections that screen for an old sRGB profile that libpng flags as “incorrect”, apparently on the grounds that using this old sRGB profile on non-Windows operating systems might violate somebody’s copyright. I’ve never found any text on the internet to confirm that “someone” put such a restrictive copyright on this particular sRGB profile. This profile is embedded in many, many images posted to the web and is still being used on even relatively new Windows machines and so is still being embedded in images posted to the web. It’s a very difficult profile to avoid.

libpng has additional code that screens for the possibility that someone might have modified the sRGB profiles that can be downloaded from color.org.

So there’s nothing “incorrect” about profiles flagged by libpng, except that libpng is playing “profile police”.

On the one hand, I agree 100% that people should respect copyrights.

On the other hand, as far as I know no-one has ever provided the actual written copyright that would indicate that one particular widely used sRGB profile “shouldn’t” be used on non-Windows systems.

The libpng furor over that profile and other profiles has taken the additional stance that the profiles are no good because they violate the ICC profile specs. Well, the particular sRGB profile I mentioned above does violate the V4 specs, but it doesn’t violate the V2 specs, and when the profile was made, V4 specs didn’t exist.

Except that this particular widely used sRGB profile and also many, many other V2 profiles in circulation do violate the the latest version of the V2 specs, which were “updated” by the ICC to reflect V4 specs. This is a case of “rewriting history to suit the winners” as there was a great deal of debate over how to handle absolute colorimetric intent. The outcome of this debate is why a lot of software still uses V2 ICC profiles interpreted according to “non-updated” V2 specs.

Obviously the swapped primaries make the profile in the referred to test image in some sense “broken”, but that’s not up to libpng to decide, and I suspect that’s not the actual or only reason the profile in the test image gets flagged by libpng.

I would suggest two things:

If you want to modify a profile, make sure the profile copyright allows to do this. My github ICC profiles and code have appropriate free/libre licenses for modifying both the code and the provided profiles.

If you are a software developer, please read through the following GIMP bug reports and libpng discussions - the order listed is the order in which the conversations took place - and decide for yourself how you want to handle libpng warnings. But I urge you to disable these warnings to the point where they don’t even print to the terminal (this is possible to do). Color management is difficult enough, and users shouldn’t have to deal with bogus/useless/misleading/uninformative libpng warnings.

1 Like

Thanks for the info, @Elle. Evidently the problem is messier than I realised – “profile police” indeed!

On my to-do list is to understand the making and use of ICC profiles more than I currently do. Your pages and resources will certainly help.

Agreed.

Thank you @Elle.

Concerning RawTherapee, @agriggio already proposed a solution.

I’m happy to see this whole discussion, and everything done in one day!

Actually I probably should have posted the png information in its own thread. I wasn’t responding to a specific problem with RawTherapee’s handling of png files. Instead I was pointing out what I see as some very serious issues with the libpng code, that most people probably aren’t aware of. I was planning to post the information anyway. But this thread’s title “PNG test image with broken profile” made it seem like starting a new thread wasn’t necessary.

The libpng code functions as “DRM” for ICC profiles, which in my opinion is a very bad thing for any file format software to do, in fact a very bad thing for any software to do. What’s next? Should raw processing and image editing software start screening for copyright violations, maybe not only for ICC profiles but also for images?

Again, I’m not condoning copyright violation. I’m saying it’s not appropriate for file format software to also function as DRM software. I’m also saying that in my opinion the only reasonable way to handle the various “warnings” issued by libpng is to take advantage of the libpng code that allows to silence these warnings, and make sure the warnings don’t have any effect on users trying to open png images.

It seems that only one link that I gave above has been clicked through to see what the link leads to. This is something I normally don’t care about one way or another when I provide links. But in this particular case, the links lead to discussions about libpng that raise issues that I think are very important for free/libre software developers (not just RawTherapee devs) to think about.

The counter is not increased when you right click and open in new tab.

I read all three links yesterday, by right-clicking (as I always do, so I’ve still got “this” page open). Fascinating discussions. I agree about DRM. I didn’t understand why some people advocated libpng checking for “real” sRGB profiles. If I understand correctly, sRGB doesn’t mandate particular mechanics for transformations, and two different profiles can yield different results but both comply with sRGB.

I’ve also downloaded @Elle’s software, which I intend to hack to make a GBR profile that the profile police won’t object to. Obviously I’ll call it something distinctive, snibgoGBR2.icc or something. I’m happy for anyone to do whatever they want with it, but I’m unsure what to put in the copyright field. It will be almost entirely based on Elle’s work, but I don’t want people blaming Elle for my wierd profiles, so should I put copyright as Elle and me, or just me, or even leave it blank? (The only reason I copyright my published stuff it to prevent anyone from preventing me doing what I want with it.)

Hi @snibgo - If you modify and distribute the code for making the profiles, the code copyright specifies certain terms - it’s a standard GPL copyright.

With respect to the profile copyright, please feel free to put your own copyright and use requirements in the profile copyright tag. I’m not the person making or modifying profiles that you make or modify, so there’s no reason at all to mention me in the copyright tag or file name for profiles you make or modify.

In fact there’s a good reason not to put my name in your profile copyright tag or file name: The reason I put “elle” in the file names for all the profiles in my github profile pack is so people know who to blame without having to actually examine the profile copyright tag :slight_smile:

Regarding the counter, I also almost always right click to open links in a new tab. I didn’t realize this doesn’t increase the counter. Oh, well. it’s nice to know someone read through the links :slight_smile: . I don’t think the person who wrote the profile-checking code is likely to change their mind about “checking profiles”. But developers who write code that reads and writes png files can protect users from confusion and possible file loss (at one point GIMP was treating the png warnings as errors, and not handling the errors very well).

The good news is that recent versions of libpng do allow considerable leeway in handling the profile-checking portions of the png code.

I also read the three links (another right clicker), although I’m not a developer and didn’t have anything constructive to say, in fact I could only think of very negative things to say about libpng, suffice to say I agree with @elle 's point of view.

Hi @james

The reason I mentioned “developers” specifically is because devs are the people with the ability to write the code that keeps users from having to deal with the various libpng profile warnings. I didn’t mean to imply that the topic wouldn’t be of interest to people who aren’t actively developing software :slight_smile:

Despite the unhelpful and confusing libpng profile warnings, png itself is a useful and very important file format, written to provide an alternative to gif, to avoid a serious software patent problem with gif files. This page explains the problem very well:

Why There Are No GIF Files on GNU Web Pages
https://www.gnu.org/philosophy/gif.html

Despite my concerns about the profile checking part of the code, png has always been one of my favorite file formats. I have a great deal of respect for the people who develop, contribute to, and maintain libpng, even though the profile checking code seems very wrong for so many reasons. But at least the libpng devs have included code for newer versions of libpng that make it easy for devs of software that supports libpng to not show the warnings and not treat the warnings as errors.

1 Like