In the floating-point API function `png_set_mDCv` we incorrectly
divided by two the chromaticity values before passing them on to
`png_set_mDCv_fixed`.
Reported-by: Mohit Bakshi <mohitbakshi2205@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Internal changes only.
Move chunk length checks to fewer places:
Change `png_struct::user_chunk_malloc_max` to always have a non-zero
value, in order to avoid the need to check for zero in multiple places.
Add `png_chunk_max(png_ptr)`, a function-like macro defined in pngpriv.h
which expresses all the previous checks on the various USER_LIMITS and
system limitations. Replace the code which implemented such checks with
`png_chunk_max`.
Move the malloc limit length check in `png_read_chunk_header` to
`png_handle_chunk` and make it conditional on the chunk type.
Progressive reader: call `png_read_chunk_header`.
Correct the handling of pHYs.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This is a major change required by the new PNGv3 colour chunk precedence
rules. It **does not** change the libpng API (png.h) however it changes
the following handling of PNG files:
IFF the PNG file contains colour space information it changes from the
libpng v3 behaviour to the now compulsory PNG v3 behaviour:
1) libpng no longer invalidates colour space chunks because they are
inconsistent.
2) libpng no longer responds to the "png_get_" APIs positively if they
are not present in the PNG but can be deduced from the colour space
chunks that are present.
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>
For the sake of completeness:
* Add the cICP entry to the list of known chunks to ignore inside
`png_set_keep_unknown_chunks`.
* Handle cICP in `png_read_end`, alongside cHRM, gAMA, iCCP, sRGB.
* In pngtest.c, move the cICP test code near cHRM, gaMA, iCCP, sRGB.
This is a cherry-pick of commit 27c2ac722fd99b8622cead655034208ce96346ac
from branch 'libpng18'.
Reviewed-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>
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>
EXIF data can be stored in an eXIf chunk before IDAT, or after IDAT,
but the entire PNG datastream may contain one eXIf chunk at most.
Introduce the private mode flag PNG_WROTE_eXIf, which is meant to be
used like the PNG_WROTE_tIME flag. The eXIf chunk and the tIME chunk
have the same ordering rules (i.e. no constraints are imposed), and
the same multiplicity rules (i.e. no multiples are allowed), and they
should be initialized and checked using the same algorithm.
This fixes commit cd03aaf7bf0e0c748b8c6cb34a56b402b40d61d0,
previously reverted in 3d57708c9166419b7f5e0bbda2f7a2149112c844.
Reported-by: Ben Bullock <benkasminbullock@gmail.com>
Set the PNG_FREE_PCAL flag immediately after the allocation of the
first pCAL buffer, so that, if any one of the subsequent allocations
fail, all pCAL buffers still get deallocated by png_free_data.
Also reorder the initialization of other PNG_FREE_ flags (without
altering the semantics) to improve the overall consistency inside
the pngset.c module.
Co-authored-by: Philippe Antoine <contact@catenacyber.fr>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This leak was discovered by OSS-Fuzz.
The old structure of the code was along the lines of:
allocate trans_alpha;
if (problem) {
// Jumps away from this function
png_warning("tRNS chunk has out-of-range samples for bit_depth");
}
mark trans_alpha as to-free;
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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.
in pngwrite.c, and made various other fixes to png_write_eXIf().
Eliminated png_ptr->num_exif member from pngstruct.h and added num_exif
to arguments for png_get_eXIf() and png_set_eXIf().
