libpng warning: sRGB: out of place !

[sunmooncode]

This error appeared when I used the Python running program, where does this warning come from and how do I get rid of it?

[jbowler]

The warning indicates that a chunk (sRGB in this case) is in the wrong place in the PNG file/datastream. The file or stream needs to be fixed. The sRGB chunk has to occur before both PLTE and the actual data (IDAT), as do all encoding chunks (gAMA, cHRM, ICC chunks etc.)

[sunmooncode]

I need your help! I keep getting this warning message when I try to access a lot of data, and some of the images are causing it to pop up. Can you suggest any steps I can take to remove or temporarily disable this warning?

[jbowler]

This is nothing to do with libpng; libpng makes a function call in response to an image with a detectably misplaced chunk (sRGB in this case). You need to identify the program making the bogus images and report a bug there. As for the warnings the handling is a choice of the app you are using, apparently Python; talk to the devs of the Python reading code you are using.

In other words this is not a libpng issue.

[jbowler]

@ctruta - not-a-bug, by-design, as-intended, etc. On the other hand if the WC3 current proposals are accepted pngtest.png will become an invalid PNG.

I suggest that libpng get out of the business of being the PNG police; delete all the warnings and handle all the errors. It will serve you much better than having libpng being the boot boy.

[jbowler]

@ctruta; a general comment, it would be better if warnings were not output unless the user of libpng explicitly adds a warning handler. There are too many cases of poorly written app code producing reams of warnings and they are clearly ignored. In this case presumably some other PNG support code is writing an out-of-place sRGB. I'm not sure whether doing this is a libpng 1.x thing or a 2.y thing. It's an easy quiet API change.

[ProgramMax]

@sunmooncode: @jbowler is correct that the png file is the real problem, not libpng. The file itself is an invalid png file. libpng is trying its best to process what it can, and is kindly alerting you that there is a problem in the file. The proper fix is to fix the broken file, not silence the helpful alert.

But if you really cannot fix the broken png files and must silence the warning, you can call png_set_error_fn() before parsing the png files.

On the other hand if the WC3 current proposals are accepted pngtest.png will become an invalid PNG.

It is already an invalid PNG with old PNG specs. This is not new to current proposals.
PNG spec, 2nd Edition, §4.8 Error Handling says "Errors in a PNG datastream...or misplaced chunks"
This wording is unchanged in the current W3C proposal.

It also says in §13.2 Error Handling "c. Provide helpful messages describing errors, including recoverable errors."

I personally agree with @jbowler on libpng deciding to handle errors or not. I believe it is the job of the application which uses libpng to provide these helpful error descriptions, not libpng itself. libpng doesn't know the context it is being used in, and thus cannot know how to provide helpful error descriptions. A print to stderr will work in a console app but might not be seen in a GUI app or web app. Further, the error message is in English, which might not be the language of preference while being used.

However, although it would be easy to default silence these warnings, it would be difficult to add good error reporting of these cases back to the user of the library. That would require a big library & user code change to accommodate. This is problematic.

Without a major libpng API change, a library user will need to call png_set_error_fn() and strcmp() the error message they are given to know how to properly route the error handling within their code. They might also need to look inside the png_ptr, which I believe we don't want them to do (it is an opaque object, right?). For example, strcmp() on "out of place" is not enough. Was the sRGB out of place? Was the iCCP?

I think our best short-term option is to simply show png_set_error_fn() calls in example code and expect users to print the English error message they're given. That way we can treat the existing behavior as a fallback if the application fails to provide their own error handling. In that case, the assumptions libpng is making are better than nothing.

I think our best long-term option is for a new error API that uses error codes.

[jbowler]

@ctruta: pulling you in because it relates to some changes I'm intending suggesting for 1.8.

There are two issues here. One is the reported one that libpng (apparently) was producing "pop ups" that caused inconvenience for the OP as a result of some of their data being poorly constructed. That's what I term the "warning message" problem which was in a separate issue about the warnings for the known-incorrect sRGB profile. The partial solution to that is simple but a quiet API change; require the app to supply a warning handler. The better solution is the ERRNUM one which, alas, was effectively abandoned around 20 years ago. Deserves a second look.

The other issue is out-of-order chunks which was argued out of court here:

http://libpng.org/pub/png/spec/1.0/PNG-Ordering.html

The fact of the matter is that an editor can introduce PLTE into a data stream with no PLTE (anything not color type 3). The safe approach (at present) is to introduce the PLTE immediately before IDAT but that is not mandated by the spec. It was discussed intermittently on png-mng-misc IRC, there was at one point an idea not to define chunk ordering WRT PLTE.

I'm certainly amenable to the obvious solution of treating PLTE as critical only for color type 3, so in other cases it is pLTE. Chris (@ProgramMax) this is where you come in. It's a relaxation of the rules so it might not cause discombobulation for anyone (well, except it will).

My general solution is that order rules with respect to optional critical chunks shall not be made.

You will both note that the OP did not supply a test image; we don't know if it was colourmapped or not. The Python code was probably PIL which so far as I can determine uses ImageIO.

[jbowler]

Also #482 and there is a separate bug IRC which observes that a similar tRNS/PLTE mis-order doesn't produce a diagnostic but I haven't re-found that one yet (I think unlike #482 that it is probably still open.)

[jbowler]

Observation: I don't think it's possible to write an LR parser for PNG because of the "after PLTE" chunks. They seem to require infinity look-ahead to determine whether the PNG has valid syntax. There are three problem chunks in the v3 spec:

https://www.w3.org/TR/png-3/#5ChunkOrdering

(Look for "After PLTE") bKGD, hIST and tRNS are required to appear after PLTE because the validity check in a type 3 (colour mapped) image depends on the entries in the PLTE:

bKGD: With colour type 3 and only with colour type 3 bKGD is an index into the palette, otherwise it's meaning is independent of PLTE.
hIST: requires a preceding PLTE for any colour type.
tRNS: interpretation depends on colour type, as with bKGD, and as with bKGD it is invalid if it has a higher palette index than PLTE (i.e. it has more entries than PLTE).

So amongst the chunks mentioned in PNGv3 only bKGD and tRNS create issues in the parser. (There may be other approved chunks with the "After PLTE" rule but I can't remember any).

@ProgramMax: typo in the spec, mDCv and cLLi are safe-to-copy so can only have the "before IDAT" ordering rule. (They don't change if an editor changes the colour type because they are independent of it, this is why they are safe-to-copy.)

[ProgramMax]

I had to read a bit to figure out why a color type other than 3 might provide a PLTE chunk.
Apparently, it is optional for truecolor images. The intention is to provide a suggested palette fallback in case the display is not truecolor. That said, the sPLT chunk is recommended for that case instead.

But, sPLT entries are larger. If the user is on a non-truecolor display, it is reasonable to think they're also limited elsewhere (like memory and file size). So a content creator could prefer PLTE over sPLT. But I imagine this is such an incredibly rare case today the the content creator would rather just not provide a palette at all. I've certainly never seen it.

---

The chunk ordering rules are only so data doesn't get processed twice. For example, if the image is decoded & displayed on screen and THEN an iCCP chunk says it should be in a different color space, the image needs to be redrawn (which results in a visual pop to the user) and possibly decoded again (if the data isn't saved).

So in the case of a chunk which does not impact future processing, I imagine there is no need for an order restriction. An unused palette could effectively come anywhere in the data stream. But the only reason to provide a palette is because it might be used. Both PLTE and sPLT

---

Also, @jbowler I don't understand why you keep trying to pin things on the Third Edition of the spec. Those ordering requirements have been in the spec since 1.0, §4.3. Summary of standard chunks (search for "before plte"). You keep doing this and it undermines your claims. And what do you have against Third Edition, anyway??

The only Third Edition changes here are the addition of the new chunks, acTL, cICP, mDCv, cLLi, eXIf, fcTL, and fdAT.
(Notice, PNG 1.1 added iCCP, sPLT, and sRGB. 1.2 added iTXt.)

That said, I think you are right about mDCv and cLLi. From the spec, "This bit defines the proper handling of unrecognized chunks in a datastream that is being modified." If I open a png in an editor and I modify it (suppose I draw on top), I think the editor should not copy those unrecognized chunks into the output. Whatever I drew would not have used the mDCv & cLLi.

---

However, all of these are pretty far off topic. We can discuss them in a separate issue(s).
For this issue, I think we should add png_set_error_fn() to the examples, open a separate issue to consider a potential new error reporting scheme, and then close this one. Agreed?