[Libav-user] Questions about ColorSpace conversion in swscale

[Markus Pfundstein]

Hi Carl,

thanks for your answers. Please see my remarks.

>> Assume I have YUV422 BT 601 input and I want my output
>> to be YUV444 FullRange. Is this possible without telling
>> SwsContext that my input source is BT 601?

> How is this supposed to work?
> (Assuming libswscale is a black box and without discussing
> its internals: How would it know what you want if you
>don't set the appropriate options?)

Yes, you are right. I think the user has to specify what the input color
space is. Its quite logical actually.

>> Also, does swscale first transform the input color
>> space to XYZ and then transform it further into the
>> target color space?

> (Sorry if I misunderstand XYZ)
> This sounds very slow, some conversions use yuv420p as
> intermediate format (this is what is generally needed
> for video). It is possible to use yuv444p instead, at
> least for some conversions.

If yuv420p is used as an intermediate format, wouldnt that result into
heavy information loss? Assume I want
to convert from rgb fullrange to yuv444 BT709. If the intermediate color
space would be yuv420, my chroma samples
would be quarted and then again interpolated. Thats not acceptable I guess.
Thats why I was wondering if XYZ is
used as intermediate format as it can store all color spaces that exist.

>> And why is there no yuv2rgb function but only a
>> rgb2yuv function?

> I believe many such functions exist.

Couldn't find them. But I must dig further into the source code. For the
beginning, it would be great to get high level
overview over how swscale is working.

>> If I want my output color space to be rgb, such a
>> function would be needed or not?

> Does yuv->rgb conversion not work for you?

It does. Sorry for the missunderstanding. Everything works fine. I do 10bit
and 12bit conversion with yuv2yuv, rgb2yuv, yuv2rgb etc.
The color space is my big question mark.

> I cannot answer some of your questions: If no 16 bit
> path exist for a conversion you need, it should be
> possible to add it but currently your information
> about what you need is very vague.

This is something I would like to know from the swscale developer. Are
there 16bit paths or is the conversion done via 8bit? This would
be a big loss.

> Carl Eugen

Thanks


On Mon, Aug 18, 2014 at 7:39 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Markus Pfundstein <markuspfundstein86 at ...> writes:
>
> > Assume I have YUV422 BT 601 input and I want my output
> > to be YUV444 FullRange. Is this possible without telling
> > SwsContext that my input source is BT 601?
>
> How is this supposed to work?
> (Assuming libswscale is a black box and without discussing
> its internals: How would it know what you want if you
> don't set the appropriate options?)
>
> > Also, does swscale first transform the input color
> > space to XYZ and then transform it further into the
> > target color space?
>
> (Sorry if I misunderstand XYZ)
> This sounds very slow, some conversions use yuv420p as
> intermediate format (this is what is generally needed
> for video). It is possible to use yuv444p instead, at
> least for some conversions.
>
> > And why is there no yuv2rgb function but only a
> > rgb2yuv function?
>
> I believe many such functions exist.
>
> > If I want my output color space to be rgb, such a
> > function would be needed or not?
>
> Does yuv->rgb conversion not work for you?
>
> I cannot answer some of your questions: If no 16 bit
> path exist for a conversion you need, it should be
> possible to add it but currently your information
> about what you need is very vague.
>
> Carl Eugen
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140819/0449ab6a/attachment.html>