In particular remove config_components.h in order to avoid unnecessary
rebuilds.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This filter is designed to parse embedded ICC profiles and attempt
extracting colorspace tags from them, updating the AVFrame metadata
accordingly.
This is intentionally made a separate filter, rather than being part of
libavcodec itself, so that it's an opt-in behavior for the time being.
This also gives the user more flexibility to e.g. first attach an ICC
profile and then also set the colorspace tags from it.
This makes #9673 possible, though not automatic.
Signed-off-by: Niklas Haas <git@haasn.dev>
This filter is designed to specifically cover the task of generating ICC
profiles (and attaching them to output frames) on demand. Other tasks,
such as ICC profile loading/stripping, or ICC profile application, are
better left to separate filters (or included into e.g. vf_setparams).
Signed-off-by: Niklas Haas <git@haasn.dev>
This introduces an optional dependency on lcms2 into FFmpeg. lcms2 is a
widely used library for ICC profile handling, which apart from being
used in almost all major image processing programs and video players,
has also been deployed in browsers. As such, it's both widely available
and well-tested.
Add a few helpers to cover our major use cases. This commit merely
introduces the helpers (and configure check), even though nothing uses
them yet.
It's worth pointing out that the reason the cmsToneCurves for each
AVCOL_TRC are cached inside the context, is because constructing a
cmsToneCurve requires evaluating the curve at 4096 (by default) grid
points and constructing a LUT. So, we ideally only want to do this once
per curve. This matters for e.g. ff_icc_profile_detect_transfer, which
essentially compares a profile against all of these generated LUTs.
Re-generating the LUTs for every iteration would be unnecessarily
wasteful.
The same consideration does not apply to e.g. cmsCreate*Profile, which
is a very lightweight operation just involving struct allocation and
setting a few pointers.
The cutoff value of 0.01 was determined by experimentation. The lowest
"false positive" delta I saw in practice was 0.13, and the largest
"false negative" delta was 0.0008. So a value of 0.01 sits comfortaby
almost exactly in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
Related to #9673, this helper exists to facilitate "guessing" the right
primary tags from a given set of raw primary coefficients.
The cutoff value of 0.001 was chosen by experimentation. The smallest
"false positive" delta observed in practice was 0.023329, while the
largest "false negative" delta was 0.00016. So, a value of 0.001 sits
comfortably in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
These are needed beyond just vf_colorspace, so give them a new home in
colorspace.h.
In addition to moving code around, also merge the white point and
primary coefficients into a single struct to slightly increase the
convenience and shrink the size of the new API by avoiding the need
to introduce an extra function just to look up the white point as well.
The only place the distinction matters is in a single enum comparison,
which can just as well be a single memcpy - the difference is
negligible.
Signed-off-by: Niklas Haas <git@haasn.dev>
Paul B Mahol
Andreas Rheinhardt
Thilo Borgmann
Jan Ekström
Niklas Haas
Michael Niedermayer