This adds APIs to get/set the two remaining new PNG-v3 colour space
chunks. The mDCV API matches that of cHRM. Both chunks support
floating point APIs (all values in the two chunks are real numbers).
Both chunks have a new encoded type, a four-digit-precision fixed-point
number, which cannot be represented in the existing `png_fixed_point`
type, so a `png_uint_32` is used.
Test examples for cICP, cLLI and mDCV are now in pngtest.png, and a
necessary change to the pngunknown.c test program has been made to
accomodate the additions.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Apply the following corrections and improvements:
* Add a validity check in `png_set_cICP`.
* Fix the ordering check in `png_handle_cICP`.
* Add a multiplicity check in `png_handle_cICP`.
* Optimize the implementation of `png_write_cICP`.
* Remove an unnecessary preprocessor guard from pngtest.c.
* Update the dependency declaration in pnglibconf.dfa.
* Fix the indentation where necessary.
This is a cherry-pick of commit c2a02691df1ecf51b7c97142752a7034350cb1f6
from branch 'libpng18'.
This chunk was added in the third edition of the PNG specification and
contains Coding Independent Code Points (related to color space
description). It is fairly simple as it only contains four fields of one
byte each: Colour Primaries, Transfer Function, Matrix Coefficients,
Video Full Range Flag.
The test file originally comes from the related WPT test case:
https://github.com/web-platform-tests/wpt/blob/master/png/support/cicp-display-p3.png
Note that I reencoded the file to make it match libpng's default
encoding parameters (it only modifies the IDAT chunk).
This is a cherry-pick of commit 65925ad4b2cbed934d5d850fe764dc46c4becbcb
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Move the definitions of interlace arrays to the top of their respective
translation units, to reduce their repeated copying in various places of
the codebase.
TODO:
As they still exist in three copies, in pngpread.c, in pngrutil.c, and
in pngwutil.c, they should all be further moved to a common place.
This is a cherry-pick of commit 620a2b73b22df66ed099e1faacac2d92f48252b7
from branch 'libpng18'.
The leading blank lines are apparently an artefact of an older source
control system. They are not required and they look like accidents,
because starting a source file with a blank line is not a regular habit
of software developers nowadays.
This is a cherry-pick of commit 37cc20add8fb5b83bb5299a26cd3b41e0f776017
from branch 'libpng18'.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This removes the default build of an undocumented feature to disable
Adler32 checksums on those systems where it was the default.
The PR is motived by github #187 however it fixes a much more general
problem (#187 is limited to an issue where libpng "crashes" on some
manufacturer systems). The fix is based on a suggestion by @sgowdev who
is the originator of the issue.
When libpng disables the checking of Adler32 checksums it does so by an
undocumented and therefore possibly unsupported call to a zlib function
which does not exist in some versions of zlib.
Fortunately libpng only does this if the caller of libpng explicitly
asks for it to happen. Unfortunately the call to the undocumented
function is still in the compiled and built libpng and this means that
on some systems (as identified in #187) libpng can fail to load or maybe
even crash.
The libpng authors are currently unaware of any program or system that
uses this feature and none has been identified by the contributors to
In this fix an option is added to *enable* the code so that by default
the code is *disabled* - this is a simple generalization of the
suggestion by @sgowdev.
BENEFITS: the problem is eliminated, users of the functionality, if any,
are idenfified, the functionality can be implemented correctly in the
future or it can be removed. Hardly anyone complains.
COSTS: someone will complain that they have to enable an option in a
libpng build to use a feature that never worked consistently in the
first place.
This patch has been tested both with the option enabled and with it
disabled via pngusr.dfa. Tests, checks pass with cmake and configure,
make distcheck passes on configure.
Reported-by: Stephen Gowen <dev.sgowen@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Import Chromium commit
e87a029871
Add the author to the list of libpng contributing authors.
Portions from the original commit message follow:
***
A recent change to libpng [1] (included in Chromium with the recent
libpng update [2]) turns chunks that are bigger than
PNG_USER_CHUNK_MALLOC_MAX into failures. Although this matches the
intent of PNG_USER_CHUNK_MALLOC_MAX, it also causes images which used to
be viewable in Chromium to fail. Changing to a benign error allows us to
display these images once again. Though it means we do allow libpng to
allocate more than PNG_USER_CHUNK_MALLOC_MAX, it matches the behavior
prior to [2] (when we were using 1.6.22), and it does not regress
crbug.com/117369
[1] 347538efbd
[2] f82653a473
***
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=827754
Co-authored-by: Leon Scroggins III <scroggo@google.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The check should fail if the EXIF byte-order header doesn't start with
a correct character, or if the two heading characters aren't identical.
Rewrite the check to make the code logic easier to follow.
The hIST chunks, used for storing image histograms, contain arrays of
16-bit unsigned integers, and the chunk size is expected to be an even
number. Raise a png_chunk_benign_error() if a hIST chunk fails to meet
this expectation.
Reported-by: Eugene Kliuchnikov <eustas@google.com>
The following pointer subtraction was unnecessary:
((const char*)(ptr)-(const char*)0)
In order to avoid further warnings about casting a wide pointer type
to a narrower integer type, we cast the pointer to the target integer
type through (size_t).
Also fix a comment and reformat the surrounding code.
Problem description:
Imagine a bitstream with an eXIf data segment that has invalid CRC.
If png_crc_finish() fails at line 2090, info_ptr->eXIf_buf is not freed
(despite the free_me setting at line 2062) because png_free_data() is
not called. png_read_info() is actually looping several time over the
png_eXIf chunk, calling png_handle_eXIf() several time in a row without
freeing the buffer.
This patch fixes the problem by leaving info_ptr's content in a clean
state in case of failure, as it is done at line 2084.
As per the const correctness rules, top-level const-ness of data
in automatic scopes does not propagate outside of these scopes
(unlike const-ness at lower levels, such as pointers to const data).
Previously, const was used liberally, but inconsistently across the
libpng codebase. Using const wherever applicable is not incorrect.
However, _consistent_ use of const is difficult to maintain in such
conditions.
In conclusion, we shall continue to use const only where doing so is
strictly necessary:
1. If a function guarantees that it will not modify an argument
passed by pointer, the corresponding function parameter should be
a pointer-to-const (const T *).
2. Static data should not be modified, therefore it should be const.
Reference:
Google C++ Style Guide
https://google.github.io/styleguide/cppguide.html#Use_of_const
In v1.6.0, compiler support for const became a requirement.
It should be used consistently. To maintain backwards compatibility,
PNG_CONST is still maintained in deprecated form.
In v1.6.0, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
