Washed out colors

[katzenjoghurt]

Hi guys. :)

Can someone give me a hint why the colors seem to change a bit in my encodings?

Look at the old lady in my attachment... it's subtle but her skin color is a bit less warm in the recoded video.


Changing the colormatrix to 1 (bt709) didn't help.


(Would be happy to provide a link to some image comparison site... but I didn't find one. Let me know if you know of one.)


Original: https://abload.de/img/x_originalh3pww.png
Recode: https://abload.de/img/x_recode8dq57.png


Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min
Bit rate : 2 902 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.058
Stream size : 47.4 MiB (100%)
Writing library : x265 2.5+14-2718cb5dd67f:[Windows][GCC 7.1.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=3285 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=24.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No


Another Example:


========================


Original: https://abload.de/img/original22knl.png
Recode: https://abload.de/img/recodeujk9j.png

ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 14 min
Bit rate : 4 541 kb/s
Width : 1 920 pixels
Height : 824 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.120
Stream size : 4.27 GiB (79%)
Writing library : x265 2.5+14-2718cb5dd67f:[Windows][GCC 7.1.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x824 / interlace=0 / total-frames=193833 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=5 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No

[jd17]

This is nothing to worry about.

Your sources are 8bit and you encode in 10bit.
What you are seeing here is most likely suboptimal 10bit to 8bit dithering of your PC software player.

If you either output the file directly as 10bit or use a player with good 10bit to 8bit dithering, the colors will look just like in the source video.

[Atak_Snajpera]

I see nothing wrong between original and reencoded. They are almost identical in terms of luma levels.
http://i.cubeupload.com/4U7daY.png

[LoRd_MuldeR]

Quite possibly a "PC-Levels" vs. "TV-Levels" issue in the playback software (video renderer). What playback software and renderer are you using?

[katzenjoghurt]

Hey. Thanks for your replies! :)

I used the video comparison tool in StaxRip.

[Ma]

It looks similar to issue #365 -- you can take a look
https://bitbucket.org/multicoreware/x265/issues/365/color-degradation-when-encoding-in-10-bit

[raffriff42]

Encode is softer, less noisy (noise in source gives subjectively brighter appearance) and dithered.

[Gravitator]

Хай!
Provide samples of the source and encoded files.

[Disturbance]

Hi, thought I would contribute as I am having the same issue with this and have not found any kind of solution.

Source: https://i.imgur.com/SFKiYx4.png
Recode: https://i.imgur.com/pOOmQlx.png

Source clip: https://www.dropbox.com/s/fc7gydmjuiasd92/Source%208bit%201080p.mkv?dl=0

Recode clip: https://www.dropbox.com/s/f83u8u459h7qaly/Encode%2010bit%201080p.mkv?dl=0

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 7s 132ms
Bit rate : 1 515 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.030
Stream size : 1.29 MiB (98%)
Writing library : x265 2.5+14-2718cb5dd67f:[Windows][GCC 7.1.0][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=171 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=45 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=2 / tu-intra-depth=2 / limit-tu=4 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=0.60 / psy-rdoq=1.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=16.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=0.70 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

In the Recode it seems to make browns turn more green (see the door in the frames I linked). I have tried encoding in 8bit and 10bit, even using x264 has the same effect. Would anyone have any idea on how to prevent it?

[Ma]

Hi, thought I would contribute as I am having the same issue with this and have not found any kind of solution.

There are 2 reasons of greener, darker and with pattern movies:

1) If you encode from high bit depth source and in MeGUI there is a line
LWLibavVideoSource("F:\speed\los\ks10.mkv", format="YUV420P8")

2) If you want to watch encoded movie and you use MeGUI with line like above.

1) is danger -- the green is really encoded, 2) is not danger -- you only see green on preview window. If you have 1) and 2) -- the green effect is doubled.

SOLUTION (only to 1)
Remember your source movie bit depth (10 for example).
In 'AVS Script Creator' delete the part ', format="YUV420P8"' from LWLibavVideoSource line -- in preview you should see double width green ugliness with stripes (don't care).
In x265 option (Encoder settings -> Config -> Misc) add '--input-depth 10' option in Custom Command Line box.
Encode.

[KanarazuKatsu]

In x265 option (Encoder settings -> Config -> Misc) add '--input-depth 10' option in Custom Command Line box.
Encode.

I've tried using the "--input-depth 10" argument with x265 CLI and the estimated time to encode goes to like 2 hours (from 20 minutes if I was encoding regularly), and also, the size output is the huge, like the episode's size itself.

I've tried "--output-depth 10" as well, but it's the same result as the people who have been encoding as well (slightly darker images/loss of colour). Note: Putting this line is useless if your x265 build is already running on 10-bits, but I tested this out regardless.

Anyone else have any clues as to what to do to get the colours pretty much close to the source without the colour having to be "washed out", "dimmed", "turning cold from warm colours of source"?

Thanks!

[Arhu]

It looks similar to issue #365 -- you can take a look
https://bitbucket.org/multicoreware/x265/issues/365/color-degradation-when-encoding-in-10-bit
I'm fairly sure it's the same issue. Any news on the ffmpeg dither_macro fix, by the way?


Source clip: https://www.dropbox.com/s/fc7gydmjuiasd92/Source%208bit%201080p.mkv?dl=0

Recode clip: https://www.dropbox.com/s/f83u8u459h7qaly/Encode%2010bit%201080p.mkv?dl=0
The source file is named 8 bit but mediainfo says it's actually 10 bit. If you re-encode 10 bit to 10 bit, for some reason (inaccurate or false) dithering is applied (ffmpeg issue). Ma proposed a patch (https://patchwork.ffmpeg.org/patch/4994/) to the ffmpeg bug list but I'm not sure what the status is. He also provided a compiled patched ffmpeg version for x64 Windows (http://www.msystem.waw.pl/x265/patched.7z) that worked for me when re-encoding from 10 to 10 bit. It doesn't come with some audio libs like Opus, unfortunately.

When you actually encode from 8 bit to 10 bit I believe you don't have to worry. If you see washed out or greenish colors, e.g. in the StaxRip video comparison tool, I'm relatively sure it's just a display issue like others said in this thread, i.e. when the false or "suboptimal" dithering is applied to the 10 bit source to display on an 8 bit monitor. Colors look fine to me in MPC with MadVR.

In short, from what I gathered:
- re-encoding 10 bit sources to 10 bit is buggy -- use Ma's patched ffmpeg version
- encoding to 10 bit from an 8 bit source is actually fine but may look buggy in StaxRip or maybe others (decoding issue)

[Ma]

I'm fairly sure it's the same issue. Any news on the ffmpeg dither_macro fix, by the way?

Now the patch is bigger -- different code for full range, updated fate tests.

Patch in ffmpeg-devel mailing list https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217462.html
Patch in ffmpeg-patchwork https://patchwork.ffmpeg.org/patch/5440/

Unfortunately ffmpeg team is bored with this and no one is answering. I've compiled ffmpeg with this patch and https://patchwork.ffmpeg.org/patch/5452/ (and libx265) -- it passed fate tests, if someone wants to test compiled binary -- www.msystem.waw.pl/x265/patched.7z

[Motenai Yoda]

it apply dithering even using pix_fmt for input and output? even with -sws_dither none?

[Ma]

it apply dithering even using pix_fmt for input and output? even with -sws_dither none?

Yes, for planar YUV or gray (16 >= source bit depth > destination bit depth >= 8). It is ffmpeg behavior, it is not changed by the patch.

[poisondeathray]

I can't reproduce it with ffms2 in vaporsynth => x265 . YUV420P10 in and out. fms2-2.23.1-msvc

Post exactly how you are encountering this bug, is it though avisynth ffms2 ? lsmash ?

[Ma]

I can't open 10 bit depth source in MeGUI with ffms2 indexer. The error is:
Your AviSynth clip has the following problem:
Error in AviSynth script:
ConvertToRGB24: conversion is allowed only from 8 bit colorspace
Continue anyway?

How in MeGUI encode a file from 10 bit depth source with ffms2 indexer?

[poisondeathray]

I can't open 10 bit depth source in MeGUI with ffms2 indexer. The error is:
Your AviSynth clip has the following problem:
Error in AviSynth script:
ConvertToRGB24: conversion is allowed only from 8 bit colorspace
Continue anyway?

How in MeGUI encode a file from 10 bit depth source with ffms2 indexer?

Maybe the problem is that version of ffms2 or you're not using avisynth+ which supports additional pixel formats. Or problem with script. Or problem with megui

ffms2 works in avisynth+ too (piped to x265, --lossless), identical output to input, verified with several methods

[poisondeathray]

even ffmpeg direct decode, pipe to x265 (again YUV420P10 in , YUV420P10 out, full 10bit) , works, lossless confirmed

So 10bit to 10bit works fine . I think people having problems were introducing a 8bit step in between or improperly converting it

8bit to 10bit depends on how you do the conversion. If you dither, or not, or what kind of dithering. For example, "grid" would suggest ordered dither or pattern dither.

[raffriff42]

Error in AviSynth script:
ConvertToRGB24: conversion is allowed only from 8 bit colorspace
Try this.ConvertToPlanarRGB(matrix="Rec709") ## etc
ConvertBits(8) # , dither=0) ## dither optional
ConvertToRGB24

[poisondeathray]

RGB should be nowhere in the script, unless it's only used for preview purposes. You need to comment it out if encoding

But vdubfiltermod can be used to preview YUV420P10 directly now (or in vapoursynth, vapoursynth editor)

You need avisynth+ to use additional pixel formats

[Ma]

Try this.ConvertToPlanarRGB(matrix="Rec709") ## etc
ConvertBits(8) # , dither=0) ## dither optional
ConvertToRGB24


Thanks! ConvertBits(8) works in MeGUI.

My test is:
take any short 8-bit video and encode lossless (x265) to 10-bit
take the encoded video and re-encode it lossless in MeGUI to 10-bit
compare 10-bit videos

If I use L-SMASH Works indexer in MeGUI, the re-encoded video differs from encoded.

If I use FFMSIndex -- it is the same.

My script for ffms2 indexer:
LoadPlugin("F:\m\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("F:\speed\di\s10.mkv", fpsnum=60, fpsden=1, threads=1)
ConvertBits(8, dither=0)
#deinterlace
#crop
#resize
#denoise

So dithering in avisynth works OK (and it is optional), in L-SMASH Works works wrong and it is not optional.

[KanarazuKatsu]

Do you mind if you gentleman post some screenshot comparisons that the colours match between the source and encode? Also, I use MadVR and MPC as well, so why can I see the washed out colour?

[Ma]

it apply dithering even using pix_fmt for input and output? even with -sws_dither none?

Thanks for this hint. It will be changed soon -- with option '-sws_dither none' there will be no dithering.

[raffriff42]

Not sure if everybody knows this, but in ConvertBits dither=0 means dithering is ON, and dither=-1 or omitted means dithering is OFF.

[Gravitator]

(Would be happy to provide a link to some image comparison site... but I didn't find one. Let me know if you know of one.)


Хай!
http://screenshotcomparison.com/