#9167: Color changed when an image converting to video
-------------------------------------+-------------------------------------
Reporter: kvsico | Owner:
Type: defect | Status: closed
Priority: normal | Component:
| undetermined
Version: unspecified | Resolution: invalid
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Balling):
Replying to [comment:7 pdr0]:
> It's close, but the colors are not exactly the same
>
> It's close in MPV, MPCHC, VLC, but with the expected +/- rounding
errors.
> Original 238,77,45
> MPV 237,76,44
> MPCHC 237,77,44
> VLC 237,76,44
> FFplay 252,90,41
> Potplayer 251,89,39
>
> FFplay and Potplayer are way off
>
>
> If using 8bit YUV, I would use 709 and do it the other way with -vf
scale, because more players will have similar close values +/-3 . Every
player including FFplay, Potplayer, dozens others will look close,
including browsers
>
> Or if you want exact numbers, use 10bit YUV or RGB
MPC uses FFmpeg and does not really support sRGB in video. So does VLC
(and very old version) and FFplay. FFplay does not support colorspaces
good enough, because SDL library.
The only one player that supports those very non-standard for video sRGB
is mpv.
I do not know what version of mpv you use, but here on Windows (Windows
has much better pow function, just for example, LOL) mpv does give 238,
77, 44. Just saying, I will attach a sample.
>will look close, including browsers
No. We in Chrome use sRGB EOTF for BT.709 OETF. So you are very off here.
Unfortunately no choice here, everything else is done for sRGB ambient
light, we cannot use BT.1886 as it is for dark ambient. Maybe when we will
get TrueTone fully...
>lossy differences
There are no lossy differences on '''one''' color. At least in x264. 4:2:0
also preserves all colors, on one color that is.
>All out of gamut values have already been eliminated by definition
I would not be so sure about that, use --gamut-warning in mpv. You will be
surprised. On default setting x264 does produce out-of-gamut (unless there
is another bug in --gamut-warning). Oopsie. Use this bmp sample for
example: https://video.stackexchange.com/questions/19944/ffmpeg-bmp-to-
yuv-x264-color-shift It gives superblack.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9167#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
