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 <[email protected]> wrote: > Markus Pfundstein <markuspfundstein86@...> 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
