#165 Incorrect warning about interlace handling

[Bernhard Rosenkraenzer]

When using some applications (e.g. OptiPNG) with libpng 1.5.0, I get

Warning: Interlace handling should be turned on when using png_read_image

From a quick look at the code, I believe the warning is incorrect:
It is produced by png_read_image() if (png_ptr->flags & PNG_FLAG_ROW_INIT) && !(png_ptr->transformations & PNG_INTERLACE)

However, if the PNG being processed is not interlaced, !(png->transformations & PNG_INTERLACE) is always true because png_set_interlace_handling does png_ptr->transformations |= PNG_INTERLACE only if png_ptr->interlaced

I'm attaching a patch that fixes it, but it should be double-checked, I'm not overly familiar with libpng.

[Bernhard Rosenkraenzer]

Possible fix

[Glenn Randers-Pehrson]

I forwarded your report to the png-mng-implement list and got this response from John Bowler:

The patch is correct and should be applied to 1.5 (thank you bero):

>When using some applications (e.g. OptiPNG) with libpng 1.5.0, I get
>
>Warning: Interlace handling should be turned on when using png_read_image

The warning is produced by the apps (there are a number) that call *both* png_read_update_info and png_read_image without preceding the png_read_update_info with setting PNG_INTERLACE (via a call to png_set_interlace_handling).

I added the warning because png_read_update_info can't know that interlace handling will be turned on and interlace handling is a transform that affects the information in png_struct and (potentially) png_info. png_read_image fixes up the one case where the struct data is currently wrong (png_ptr->num_rows), so 1.5 and earlier are safe, but it's a maintenance nightmare because interlace-specific information in the libpng structs has to be special case handled in png_read_image.

Unfortunately, as the reporter of the bug observes:

>From a quick look at the code, I believe the warning is incorrect:
>It is produced by png_read_image() if (png_ptr->flags &
>PNG_FLAG_ROW_INIT) && !(png_ptr->transformations & PNG_INTERLACE)
>
>However, if the PNG being processed is not interlaced, !(png->transformations &
>PNG_INTERLACE) is always true because png_set_interlace_handling does
>png_ptr->transformations |= PNG_INTERLACE only if png_ptr->interlaced
>
>I'm attaching a patch that fixes it, but it should be double-checked, I'm not overly familiar with libpng.

That analysis is correct, and I the patch is correct - I intended png_set_interlace_handling, png_read_update_info, png_read_image to be silent!

In 1.4 and earlier the png_ptr->num_rows fixup was always done. I changed the code to only do it in the 'fixup' case and the patch further restricts the fix-up to interlaced images. This is fine because it matches correct app code that does the work of png_read_image.

It would also be worth adding a note to the changes text that apps should call png_set_interlace_handling if they call png_read_update_info; I've seen a number of apps that don't. At present they get lots of warnings, but with the change only interlaced images will cause the warning.

John Bowler <jbowler at acm.org>

[Glenn Randers-Pehrson]

Fixed in libpng-1.5.1

[Mark Colbath]

We're still getting this error with 1.5.13.