View Full Version : Is this chroma shift on bottom field ?
Music Fan
26th March 2016, 11:18
Hi,
looking at this video, I saw some problems with colors ;
http://www.dailymotion.com/video/x3yo07s
I downloaded it with Firefox's Download Helper and the 1080p version hasn't actually been de-interlaced.
Add ComplementParity() to get tff (otherwise the parity is wrong) and separatefields(), there are clearly 50 different fields per second without blending.
The strange thing is that there seems to be chroma shift only on bottom fields, thus every 2 frames when separatefields() is used, look at the hand on frames 372 and 373 (actually fields) in Virtual Dub (I didn't resize, I simply shrinked Virtual Dub's window on the right side), click twice to get full size ;
http://nsa37.casimages.com/img/2016/03/26/mini_160326112141256195.jpg (http://www.casimages.com/i/160326112141256195.jpg.html)
http://nsa37.casimages.com/img/2016/03/26/mini_160326112415162511.jpg (http://www.casimages.com/i/160326112415162511.jpg.html)
Is it due to the fact interlaced video has been encoded as progressive ?
How to solve this (without de-interlacing if possible) ?
Thanks.
TheSkiller
26th March 2016, 12:47
It is because at some point when the chroma was either downsampled to 4:2:0 or upsampled from it it was sampled as if the video was progressive – which it was not obviously – thus merging the chroma of both fields. It's as if you'd resize an interlaced video vertically without deinterlacing, but only the chroma.
Music Fan
27th March 2016, 11:19
And thus, there is no way to improve this ?
edit : maybe by comparing top and bottom field's chroma and substracting top field's chroma (which is intact) from bottom field's chroma (which contains both field's chroma) ?
But I don't know if it's possible and how if yes.
Music Fan
28th March 2016, 09:41
I tried with the Substract function but I couldn't make it work as I wanted, that's maybe not the good method for this problem.
Is there a way to compare both field's chroma (I remind that top field is ok) and exclude the differencies to recover the original bottom field's chroma ?
TheSkiller
28th March 2016, 14:39
maybe by comparing top and bottom field's chroma and substracting top field's chroma (which is intact) from bottom field's chroma (which contains both field's chroma) ?Problem is this video has 50 or 60 unique fields of luma, but the chroma is essentially deinterlaced, so only half of that. They do not match temporally anymore.
And thus, there is no way to improve this ?The only thing I can think of is completely discarding the bad bottom fields and interpolate new good bottom chroma fields with motion interpolation.
Or drop half the luma as well (keep only the top fields)... But I wouldn't really do that
Music Fan
28th March 2016, 15:47
Problem is this video has 50 or 60 unique fields of luma, but the chroma is essentially deinterlaced, so only half of that. They do not match temporally anymore.
Ok but as the top fields are ok, why wouldn't a kind of substraction work ?
The only thing I can think of is completely discarding the bad bottom fields and interpolate new good bottom chroma fields with motion interpolation.
Do you believe the top field's luma can be recovered for the interpolation to interpolate only chroma ?
If not, can it be recovered after interpolation to replace the new luma by the original ?
TheSkiller
29th March 2016, 15:45
Yes, the top and bottom field's luma can be kept untouched, as well as the top field's chroma; only the bottom field's chroma would be completely rebuilt from the good top fields.
Something like this.
Important: This script assumes a Top Field First source!
ConvertToYV12(true) #won't do anything if already YV12
AssumeTFF()
o_top=SeparateFields().SelectEven()
o_bottom=SeparateFields().SelectOdd()
Bob(0,1)
SelectEven() #keep only the good (bobbed) top fields for interpolation
#####
### Motion interpolation using SVP (https://www.svp-team.com/wiki/Download#libs)
threads=2 #adjust threads depending on CPU
super=SVSuper("{gpu:0}")
vectors=SVAnalyse(super, "{ }")
SVSmoothFps(super, vectors, "{ rate: {num:2,den:1,abs:false}, algo:13, mask:{cover:100,area:0} }",
\ url="www.svp-team.com", mt=threads)
###
#####
AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave() #undo bobbing
SeparateFields().SelectOdd() #discard original top fields and keep only interpolated bottom ones
MergeLuma(o_bottom) #replace bottom field luma with original one, keeping only interpolated chroma
Interleave(o_top, last) #interleave with original top fields
AssumeTFF()
Weave()
Music Fan
29th March 2016, 17:09
Thanks, very interesting script !
It works well, except on scenes change where there is blending ; here is frame (field) 321 (don't use Weave() at the end of your script) ;
http://nsa37.casimages.com/img/2016/03/29/mini_160329061705568368.jpg (http://www.casimages.com/i/160329061705568368.jpg.html)
Same problem with frames 1159, 1443, 1513 ...
TheSkiller
29th March 2016, 21:21
I have a suspicion about what's causing it but I need the video to make sure.
Can you please upload the video somewhere (File-Upload (http://www.file-upload.net/) for example)? I tried but I can't find any way to download from Dailymotion without installing stuff I don't want.
Music Fan
30th March 2016, 10:04
Yes (I put it in 7zip, I believe it helps in case of transfer error) ;
https://www.sendspace.com/file/lo4k7k
By the way, my script begins with ;
LWLibavVideoSource("H:\....mp4")#bff
ComplementParity()#tff
then o_top=SeparateFields().SelectEven() ...
TheSkiller
30th March 2016, 11:40
OK, so it's because of where SVP thinks the scene change should occur. I did not find any way to change this behaviour without making everything else worse.
The only fix I came up with is not using the original bottom field luma by commenting out the MergeLuma line near the end.
Music Fan
30th March 2016, 12:02
But if the MergeLuma line is after its current place, the script won't work.
Another solution is maybe to use the original fields only for the scenes change, but it's not convenient. And I don't know how to do this, maybe with trim ?
TheSkiller
30th March 2016, 12:05
But if the MergeLuma line is after its current place, the script won't work.No, what I mean by "comment it out" is put a # in front of it or delete the whole line, not move it.
Like so:
#MergeLuma(o_bottom)
Music Fan
30th March 2016, 15:28
Ok, it works without the original bottom field luma but I guess it's not as good.
And I don't understand why leaving leaving out the original bottom field luma solve this while the problem seems to come from the interpolation :confused:
By the way, as you bob the video and then add SelectEven, is this still 1080i or 540p ? Isn't your script the same than ;
SeparateFields()
SelectEven()
# Motion interpolation ...
Because the interpolation is made with the top fields.
TheSkiller
30th March 2016, 16:42
Ok, it works without the original bottom field luma but I guess it's not as good.Yes, it's not the unaltered bottom field's luma anymore but the interpolated one (alongside with the new chroma, thus they both match also on scene changes). So yeah that's not as good.
Problem is this,
so, our original sequence looks like this if we bob the fields:
[T1,B1] [T2,B2] [T3,B3]
magenta means it's the first frame of a new scene
(all scene changes occur at top fields only, which is quite normal)
Now we take only the frames of the top fields and we have:
[T1] [T2] [T3]
Now we interpolate one new frame inbetween every original one and we get this:
[T1,iB1] [T2,T3], [T3,iB3]
The algorithm cannot recover iB2 because there is nothing to interpolate it from – the next frame (T3) is a new scene. So what does the motion interpolation do? It duplicates T3 to fill the hole.
That means all scene changes are now one field earlier than originally and we lose one field at each scene change.
If we merge back the original bottom field's luma, the scene changes are just like they were before, but the chroma of course does not match at all for one field at each scene change.
By the way, as you bob the video and then add SelectEven, is this still 1080i or 540p ?Yes, because at the end I interleave the top fields back in. It's still 1080i with it's original resolution.
Music Fan
30th March 2016, 18:10
(...)
If we merge back the original bottom field's luma, the scene changes are just like they were before, but the chroma of course does not match at all for one field at each scene change.
Ok, I understand.
Yes, because at the end I interleave the top fields back in. It's still 1080i with it's original resolution.
I still have a doubt because the bottom field is created from bobbed top fields, which means simply doubled lines (without interpolation).
Thus I don't understand the difference between this process and making interpolation from non bobbed top fields (flattened fields in 540p) which would use the same lines to create the new bottom fields.
I would understand your trick if the top field was resized (from 540p to 1080p) and not bobbed, which would imply new lines creation (spatial) before interpolation (temporal creation).
Therefore I'm astonished that the original bottom field luma match with the new bottom field chroma (except on scene change) because there should be a one-line shift :confused:
TheSkiller
30th March 2016, 19:54
Thus I don't understand the difference between this process and making interpolation from non bobbed top fields (flattened fields in 540p) which would use the same lines to create the new bottom fields.It would be wrong to do any interpolation on fields, like with SeparateFields(), because of the spatial misalignment from that.
Now that we do not merge back the original bottom field's luma anymore, it would make sense to use a more sophisticated bob-deinterlacer because otherwise the bottom fields indeed lose resolution.
I would understand your trick if the top field was resized (from 540p to 1080p) and not bobbed, which would imply new lines creation (spatial) before interpolation (temporal creation).That's exactly what Bob(0,1) does, plus correcting the offset of the fields – simply resizing 540p fields to 1080p is not correct. Fields have an offset, simply doubling every line is not sufficient. See here http://avisynth.org.ru/docs/english/corefilters/bob.htm
Music Fan
31st March 2016, 09:38
Ok, I believed it was a simple line doubling.
Now that we do not merge back the original bottom field's luma anymore, it would make sense to use a more sophisticated bob-deinterlacer because otherwise the bottom fields indeed lose resolution.
Yes, but as the bottom fields cannot be used because of the chroma blend, how to de-interlace only with top fields ?
A spatial-only de-interlacer is needed.
I can also do what I said earlier ; use your script and replace only the blended fields on scene change.
I found this topic about chroma blend ;
http://forum.doom9.org/showthread.php?p=1692409#post1692409
But feisty2's script seems written for progressive source, do you believe it may work with interlaced ?
Music Fan
7th April 2016, 12:40
I continued my research and modified a little bit your script ;
LWLibavVideoSource("H:\16 03 18 Un problème technique avec la jupe d'Erika - TPMP 1080p25.mp4")#bff 1080i25
ComplementParity()#tff
o_top=SeparateFields().SelectEven()
o_bottom=SeparateFields().SelectOdd()
nnedi3(field=1)#1080p25 tff
### Motion interpolation using SVP (https://www.svp-team.com/wiki/Download#libs)
threads=2 #adjust threads depending on CPU
super=SVSuper("{gpu:0}")
vectors=SVAnalyse(super, "{ }")
SVSmoothFps(super, vectors, "{ rate: {num:2,den:1,abs:false}, algo:13, mask:{cover:100,area:0} }",
\ url="www.svp-team.com", mt=threads)#1080p50 tff
###
SeparateFields().SelectEvery(4,0,3)#undo bobbing
SelectOdd()#discard original top fields and keep only interpolated bottom ones
MergeLuma(o_bottom)#replace bottom field luma with original one, keeping only interpolated chroma
Interleave(o_top, last)#interleave with original top fields
Weave()
But I still have to replace 53 fields on scene change !
Here is the list ;
101, 321, 925, 1015, 1069, 1159, 1443, 1513, 1559, 1611, 1671, 1713, 1767, 1869, 1951, 2217, 2305, 2363, 2431, 2515, 2587, 2679, 2829, 2883, 2971, 3039, 3209, 3281, 3445, 3523, 3569, 3629, 3685, 3737, 3789, 3837, 3971, 4079, 4167, 4211, 4269, 4337, 4643, 4853, 4891, 4949, 5139, 5347, 5447, 5573, 5619, 5667, 5705.
Should I use trim or there is simpler ?
edit : I found this way to use trim but this is quite long to type ;
LWLibavVideoSource("H:\16 03 18 Un problème technique avec la jupe d'Erika - TPMP 1080p25.mp4")#bff 1080i25
ComplementParity()#tff
o_top=SeparateFields().SelectEven()
o_bottom=SeparateFields().SelectOdd()
of=SeparateFields()
nnedi3(field=1)#1080p25 tff
### Motion interpolation using SVP (https://www.svp-team.com/wiki/Download#libs)
threads=2 #adjust threads depending on CPU
super=SVSuper("{gpu:0}")
vectors=SVAnalyse(super, "{ }")
SVSmoothFps(super, vectors, "{ rate: {num:2,den:1,abs:false}, algo:13, mask:{cover:100,area:0} }",
\ url="www.svp-team.com", mt=threads)#1080p50 tff
###
SeparateFields().SelectEvery(4,0,3)#undo bobbing
SelectOdd()#discard original top fields and keep only interpolated bottom ones
MergeLuma(o_bottom)#replace bottom field luma with original one, keeping only interpolated chroma
Interleave(o_top, last)#interleave with original top fields
trim(0,100)++of.trim(101,1)++trim(102,320)#replace blended fields inaccurately interpolated
Weave()#re-interlace
This is only the debut of course.
Overdrive80
7th April 2016, 14:09
This script is really good, shared by other user (I dont remember). I hope that be useful
luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)
# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip
# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")
# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")
# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")
# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)
Tdecimate(mode=1)
http://forum.doom9.org/showthread.php?t=171134
Music Fan
7th April 2016, 16:13
Thanks, I had found your topic but I don't know if this script can be used with interlaced video.
I asked a few days ago to feisty2 (who wrote this script) but he didn't answer.
Music Fan
8th April 2016, 16:19
I tried this script in several ways (on interlaced, on separated fields, only on bottom fields) but it does not help, it's even worse.
It probably needs modifications, admitting it can work with my video.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.