Log in

View Full Version : Pb with some red color


greatfinders
11th November 2016, 19:58
Hello i try to do the best encode of my Dragon ball dvd in private way but there is a small problem i can't correct with avisynth (http://www.videohelp.com/software/Avisynth)

a guy did it in his test but i can't contact him anymore.... i explain
http://screenshotcomparison.com/comparison/184093/picture:1

in the original one you have some red around line like a chroma bleeding or halo in the guy test it is solved (watch around goku's arm) .... i try some things but nothing work
can someone help me?
thanks

here a sample:
http://uptobox.com/gnikrk1ifsuc or
https://1fichier.com/?uhlcv7do5e
i just mux it in mkv to cut it , i didn't do any re-encode

greatfinders
12th November 2016, 16:36
here a screen of the problem....it is very annoyig me and i need help for this problem i couldn't resolve myself with some search
could someone really good to help me?


http://nsa37.casimages.com/img/2016/11/03/161103115218347249.png
ere a comparison between the original and what it should have to be
http://screenshotcomparison.com/comparison/189673

wonkey_monkey
12th November 2016, 17:31
How did you take your screenshot?

I played back the clip in VLC and saw the problem. But then I loaded it via dgindex/Avisynth/VirtualDub and the problem was gone.

I tried MPC-HC and the problem was present. Perhaps media players aren't as good at chroma upsampling as they should be?

greatfinders
12th November 2016, 17:46
Thanks a lot to help me ....i take it by vlc and if i open with dgmpgdec the red thing is there

i use klite mega codec pack and with avspmod, avisynth and vdub i have this problem can this be the problem source?

http://nsa37.casimages.com/img/2016/11/12/161112060253687049.png

wonkey_monkey
12th November 2016, 18:13
I guess dgindex just has the same problem. I doubt it's anything codec related - unless you can force whatever codec is being used to output YV24 instead of YV12 to bypass the poor chroma upsampling of the players. VirtualDub and Avisynth are perhaps just smarter than the rest, and they interpolated the chroma instead of just duplicating it.

greatfinders
12th November 2016, 18:30
i have the same issue with all of them , vdub and avisynth too

kuchikirukia
15th November 2016, 10:39
Watch better anime.

greatfinders
15th November 2016, 17:04
Watch better anime.

totally useless comment.... if you cannot help me please don't answer here thanks

greatfinders
16th November 2016, 15:40
i try with ChromaShiftSP which can correct pixel without the 2 limitation but when i use it to correct the red, there is some chroma bleeding green around the feet
someone can try with the sample i upload please?
thankkkkkkkkks a lot there is almost one month i try to correct it but i fail

wonkey_monkey
16th November 2016, 23:32
I'm now not entirely clear what the problem you want to fix is.

What I see is that players - surprisingly - don't upscale chroma correctly, which leads to the alternating vertical stripes of strong/weak red.

Possibly there is also a chroma shift.

Unless you encode to yv24, which is wasteful and possibly not well-supported, you can't fix the first problem because it's a player problem, not an encoding problem. I'm still quite surprised to find the VLC and MPC-HC don't do this correctly.

The second problem is a chroma shift - easily fixed, but again you will still suffer the first problem if you use certain players, it seems.

I can only assume that no-one has ever noticed this problem because it's pretty hard to spot, or I have some other problem on my setup that causes players to act in this way.

If anyone can add anything, please do, because I'm not sure I'm getting this right.

Edit: I changed my VLC renderer to OpenGL and the bad chroma upsampling is fixed.

greatfinders
17th November 2016, 12:15
http://screenshotcomparison.com/comparison/184093/picture:1 a guy i cannot contact did it

bxyhxyh
17th November 2016, 13:36
Comparison on the original post is as exactly as davidhorman said.
Second comparison, isn't just chroma bleeding? It seems that other guy fixed chroma bleeding.
That's why those red colors you said look reduced.

greatfinders
17th November 2016, 13:47
it is not reduce but solve here with a high zoom
http://screenshotcomparison.com/comparison/189673
the one who have red is the original, the second is totally natural there is no red pixels
i have try chromashift and reduce this red things but there allways be red pixels and not seems as natural as him...

wonkey_monkey
17th November 2016, 16:11
On your latest comparison the first picture has incorrect chroma upsampling due to whatever player was used. The second picture does not. It's not a chroma shift thing.

(but the video does seem to have a chroma shift issue, once it is correctly chroma-upsampled).

Motenai Yoda
17th November 2016, 17:24
try awarpsharp2(chroma=6)

greatfinders
18th November 2016, 07:35
it is not as perfect as that guy did but if i can't contact him and combinate all your suggestion it is almost dissapear thanks a lot, if you have other suggest i can try to see if it can be better :)

Soulvomit
24th November 2016, 20:11
The problem you're seeing is because the chroma placement during playback/conversion to 4:4:4/RGB is wrong. For it to look right with AviSynth at least, add the string ChromaInPlacement="MPEG1". By default it uses the value "MPEG2" and in doing so shifts the chroma to the left, resulting in the misalignment with the luma, which gives you that red.

YUV:
ConvertToYV24(ChromaInPlacement="MPEG1")
RGB:
ConvertToRGB(ChromaInPlacement="MPEG1")
This proves that the original, stored chroma is good and where it should be and that the problem lies with how it's handled. Keep in mind each decoder will do this differently, using its own chroma placement (MPEG1 or 2) and chroma rescaling algorithm (nearest-neighbor, bicubic, Lanczos, Spline, etc.) so it's impossible for it to look the same everywhere. You'll just be chasing your tail if you try. There is nothing for you to fix so re-encode as DGIndex is serving it in YV12.