On 21 July 2017 at 00:08, Nicolas George <geo...@nsup.org> wrote:
> Le duodi 2 thermidor, an CCXXV, Rostislav Pehlivanov a écrit :
> > Many image formats support embedding of ICC profiles directly in
> > their bitstreams. Add a new side data type to allow exposing them to
> > API users.
>
> Why not make it a member of AVFrame directly? It looks to me very
> similar in principle to color_range, color_primaries, colorspace, etc.
>
>
It can be quite big. In some insane cases it can be bigger than the actual
packet or even the uncompressed frame. Its also not strictly necessary to
display something more or less looking okay, but its necessary to display
something correctly. I think its better treated like we currently treat HDR
by defining a side data type and letting the API users cache and use it,
which is what this patch does. Side data is also refcounted so it even
solves the size issue.
> >
> > Signed-off-by: Rostislav Pehlivanov <atomnu...@gmail.com>
> > ---
> > libavutil/frame.h | 6 ++++++
> > libavutil/version.h | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 26261d7e40..ee899d844d 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -134,6 +134,12 @@ enum AVFrameSideDataType {
> > * the form of the AVContentLightMetadata struct.
> > */
> > AV_FRAME_DATA_CONTENT_LIGHT_LEVEL,
> > +
> > + /**
>
> > + * The data contains an ICC profile with an optional name defined
> in the
> > + * metadata entry.
>
> Not being a specialist of ICC profiles, I have no idea what that means
> in practice. What data structure is it?
>
>
There's a 300 page document describing the bitstream and how its used. The
smallest implementation, lcms is still a few tens of thousands of lines.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
