View Full Version : ImageWrite for colorspace conversion ?
juGGaKNot
26th November 2013, 20:14
Hi guys.
I use this script :
AVIsource("orig.avi",audio=false) >> m1.avs
SelectEvery(340,0) >> m1.avs
ImageWriter("Screenshotorig", type="bmp") >> m1.avs
avsutil.exe m1.avs play
FFVideoSource("orig.mp4").assumefps(30) >> m2.avs
ConvertToRGB32() >> m2.avs
SelectEvery(340,0) >> m2.avs
ImageWriter("Screenshotencd", type="bmp") >> m2.avs
avsutil.exe m2.avs play
To compare the color of the original uncompressed video and the encoded x264 video.
Is this accurate ?
Cheers.
raffriff42
26th November 2013, 20:32
Probably not -
1. AVIsource: color model, matrix and luma range unknown. Must be verified for the particular codec in use.
2. ImageWriter: "bmp" is RGB mode, so if AviSource is YUV, an implicit conversion will take place.
3. FFVideoSource: color model, matrix and luma range unknown. Must be verified.
4. ConvertToRGB32: implicit "colormatrix=Rec.601" - which is probably wrong (images are 0-255, not 16-235)
You would have to calibrate every stage of the process, starting with an AVI (same codec) with known colors - that is, an AVI with calibrated colors that uses the same codec as the actual video you want to work with (whether H.264, Xvid, Huffyuv etc) (see here (http://forum.doom9.org/showthread.php?t=135034) maybe)
EDIT you could verify the whole signal chain at once instead of breaking it down into steps, but you might get two or more errors that cancel each other out. This would introduce subtle problems like clipping or banding, but as long as you check for those problems you should be OK.
Gavino
27th November 2013, 10:50
2. ImageWriter: "bmp" is RGB mode, so if AviSource is YUV, an implicit conversion will take place.
There is no implicit conversion. If source is YUV, ImageWriter throws an error, so AviSource must be delivering RGB here (possibly after conversion by the VfW codec selected).
juGGaKNot
27th November 2013, 18:26
Probably not -
1. AVIsource: color model, matrix and luma range unknown. Must be verified for the particular codec in use.
2. ImageWriter: "bmp" is RGB mode, so if AviSource is YUV, an implicit conversion will take place.
3. FFVideoSource: color model, matrix and luma range unknown. Must be verified.
4. ConvertToRGB32: implicit "colormatrix=Rec.601" - which is probably wrong (images are 0-255, not 16-235)
Original avi is uncompressed 4:4:4 SD so Rec.601 should be ok no ? If i use PC.601 the image is too dark.
The outputs look almost identical ( the red is not as bright on the encode but i thought that's because of the 4:4:4 > 4:2:0 conversion )
raffriff42
27th November 2013, 22:00
>Original avi is uncompressed 4:4:4 SD so Rec.601 should be ok no ? If i use PC.601 the image is too dark.
Sounds reasonable.
>The outputs look almost identical
Check the color on several media players, and don't be shocked if the color is different.
juGGaKNot
28th November 2013, 17:33
Check the color on several media players, and don't be shocked if the color is different.
That's what i'm trying to avoid, comparing the video files with media players. I'm talking about the bmp output from the script.
raffriff42
29th November 2013, 02:41
You're trying to make the two signals as consistent as possible for comparison purposes, and that's good; but I think they can be made just as consistent using Avisynth alone. The main source of uncertainty, in any case, is AviSource & FFVideoSource - and the decoders *they* call. The script below makes the two clips look the same to the media player, which is exactly the benefit of writing bitmaps, I think. #avisynth
## Perform an A-B comparison - flip between clip A and clip B
## NOTE examine this frame-by-frame, not in real time.
## Clip filters shown as an example -
## use just enough filtering to allow
## the two videos to be interleaved.
A=AviSource("orig.avi")
\ .AssumeFPS(30)
\ .ConvertToRGB32(matrix="Rec601")
\ .KillAudio
B=FFVideoSource("orig.mp4")
\ .AssumeFPS(30)
\ .ConvertToRGB32(matrix="Rec601")
\ .KillAudio
return Interleave(
\ A.SelectEven.Subtitle("A"),
\ B.SelectEven.Subtitle("B"))
EDIT thank you Gavino vv
Gavino
29th November 2013, 10:20
## use just enough filtering to allow
## the two videos to be interleaved.
Neither AssumeFPS() or KillAudio() are required for that.
All that is necessary is that the the two videos have the same dimensions and colorspace.
juGGaKNot
29th November 2013, 17:54
code#avisynth
Will try this.
All that is necessary is that the the two videos have the same dimensions and colorspace.
And when they are not the result will differ, right ? That's why i want to use it to check the colorspace on my entire chain
uncompressed > vegas > uncompressed > x264 > youtube > x264 from youtube.
raffriff42
29th November 2013, 18:18
uncompressed > vegas > uncompressed > x264 > youtube > x264 from youtube.OK given that workflow, I'd suggest an additional test:
Vegas internal colorbars > uncompressed > x264 > youtube > x264 from youtube
...Assuming "x264 from youtube" means a screen capture, not a downloaded file, since this is what the audience will be seeing. Alternatively you can set your media player to emulate the look of YouTube's player, which IIRC assumes 16-235, BT.701.
juGGaKNot
29th November 2013, 19:33
OK given that workflow, I'd suggest an additional test:
Vegas internal colorbars > uncompressed > x264 > youtube > x264 from youtube
Ok will do. As long as the test is ok i will see what comes out.
...Assuming "x264 from youtube" means a screen capture, not a downloaded file, since this is what the audience will be seeing. Alternatively you can set your media player to emulate the look of YouTube's player, which IIRC assumes 16-235, BT.701.
Won't a screen capture be affected by my gfx card settings ?
I meant a downloaded file to see if their reencoded video still looks like the original.
raffriff42
29th November 2013, 20:14
Won't a screen capture be affected by my gfx card settings ?That's a tough one. Yes, I guess, with some settings. I've convinced myself that on *my* system, a screen cap is accurate (displaying test videos and still images with known colors, and testing the screen colors with a probe such as ColorPic (http://www.iconico.com/colorpic/), then opening the capture in an image editor and probing the colors again)
juGGaKNot
30th November 2013, 18:37
That's a tough one.
Just went to a friends house and he has an old 1600x900 monitor + a hd7750 and the same video is is very dark on his screen ( i think fullrange is on )
So i have to test it for myself, i'll add some screens when done here.
Thanks to everyone.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.