The function to check the relationship between png_struct and png_info

[qiutianchloe]

Dear all:
Hi! Hope everything goes well!
I am new to use libpng library. Is there any function that could check the if a png_info is corresponding to a png_struct?
Thank you very much!

[jbowler]

That's an interesting question. The simple answer is no and, more generally, I'm not sure that such a function can be written. It's possible to determine if png_info is incompatible with the PNG in png_struct by comparing the information which is in the IHDR (see the spec); if the information matches exactly it may be possible to apply the png_info to the png_struct

If it turns out that it is always possible (I suspect it might be) then it's only a matter of matching up the IHDR information. The devil in the details is that libpng may rely on some data being shared. That wasn't the original design aim; png_info was meant to record the information from reading a PNG and encode the information for writing a PNG, so if the basic IHDR matched the design intended (implicitly) for the "info" to be able to write the "struct" (it can't read it, obviously).

I've tried this in the past and fixed bugs (there were bugs up to 1.5). I suggest you try it with 1.6 and see what happens. If it doesn't work it might be a valid bug.

[jbowler]

@qiutianchloe this is potentially important input for libpng-ng. The original design was that png_info was a description of a PNG constructed by the libpng user on write or by libpng itself on read. png_struct was just a bunch of control stuff and should have been independent of png_info.

How important/useful is this? Should libpng-ng make it so that a "png_info" can be used as a free standing structure/class or is this just a waste of effort. libpng-ng could just use one control structure or class (I think it has to have one) which reads/writes but does not store, leaving user of libpng with the task of storing data in an appropriate format.

[jbowler]

@ctruta: might be [libpng18] but I think that the message for [libpng18] is to make sure not to share data between png_struct and png_info. png_colorspace was an attempt to make this work even when the png_info was used to write a new PNG with a new png_struct but that implementation may bear review. For [libpng-ng] it seems to me that the original principles in the design were good so maybe the palette et-al sharing nonsense could be fixed... Certainly a worthy discussion.