Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th July 2008, 16:48   #1  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
gamut conversions through Avisynth ?

hello world,

there's a new SAMSUNG projector, that's ISF(Imaging Science Foundation) certified and made under the supervision of Joe Kane(he's quite a video guru)

that's the SP-A800B(DLP 1080p), and as they say "Paramount, DreamWorks, ABC, and Universal Studios are among the professional users of this model."

http://www.projectorcentral.com/Samsung-SP-A800B.htm

it's one of the very few projectors(if not the only one) where you can change the gamut on the fly.

mostly, the SD movies are encoded through the REC601 matrix, and the HD movies through REC709.

but this is the theory...

in practice(and I know that sounds crazy), the mastering engineers still use this kind of monitoring displays :



the engineer is using a BVM CRT monitor(with SMPTE-C phosphores gamut)

this thing :

http://www.sony.co.uk/biz/view/ShowP...site=biz_en_GB

so basically, SD and HD movies are not mastered on sRGB/HDTV gamuts as we've all been led to believe.

video monitors used in Europe :
SONY BVM-A14F5M (EBU phosphores)
SONY BVM-A20F1M (EBU phosphores)
SONY BVM-A32E1WM (EBU phosphores)
SONY BVM-L230 (LCD)
SONY BVM-L420 (LCD)

and in USA:
SONY BVM-A20F1U(SMPTE-C phosphores)


so basically, to see movies the way they were mastered, you'd need :

1)YCbPr decoding :

- Rec. ITU-R BT.601-5 for SD primaries (in theory only)
Y’ = 0,299R’ + 0,587G’ + 0,114B’ (601)

- Rec. ITU-R BT.709-4 for HD primaries (in theory only)
Y’ = 0,2126R’ + 0,7152G’ + 0,0722B’ (709)

2)display gamut :

- REC-601 SMPTE-C for SMPTE-C primaries (NTSC SD & HD, 90% of bluray discs as well, and some PAL DVD's)

- REC-601 EBU Tech. 3213 for EBU primaries (PAL/SECAM SD and european bluray discs)

- REC-709 HDTV (for US and EUR HDTV)


that's what my DLP projector looks like, when calibrated in sRGB(the gamut is identical to the HDTV gamut) :



and here's a gamut comparison :



so is there any AVS guru that'd be interested to find a way to get 1:1 colors with the way movies are being mastered in the first place ?

of course it'd have to 10bit if possible in order to avoid banding and stuff.

I know that sounds crazy, but that's the way it is.
this Samsung projector is the ultimate thing to watch movies "the way they were meant to be watched"(it supports sRGB/HDTV/EBU/SMPTE/etc.. gamuts).

surely enough, you could revert this colorspace hiccup in AVS ?

....and run it in realtime in ffdshow ? that'd be the shiznit

here's a list made by the french ISF CEO "Julien Berry", that lists which gamut has to be used for each Bluray movie :

http://www.wysios.com/jkp/gamut2.asp

from what he told me, here's what happens when using a display with sRGB/HDTV gamut :

Quote:
for telecines that were made on an EBU monitor, only the green primary will be off.

for telecines that were made on an SMPTE-C monitor, the colors will be over-saturated.
when you read that most of the bluray's are made on SMPTE-C monitors, and that usually you end up with over-saturated colors on sRGB/HDTV displays.....that suddenly would make a lot of sense to fix the colors.....wouldn't it ?

here's a technical PDF about gamuts :
http://www.teksite.co.kr/osilo/down/...nd%20gamut.pdf


and basically you can do this gamut conversion with a scaler :
http://www.google.com/search?hl=en&q...tnG=Search&lr=

its job is to convert gamuts, but that costs a hell lot of money(and usually only SDI input and DVI output).....so doing it in AVS in 10bit would be beyond words

some ppl have worked on it with PS scripts :
http://www.avsforum.com/avs-vb/showthread.php?t=912720

the idea would be to :

-do REC-601/REC-709 matrix conversions for SD/HD to get sRGB content
-do REC-601 SMPTE-C / REC-601 EBU Tech. 3213 > HDTV gamut conversions to get proper primaries on sRGB/HDTV displays

Last edited by pitch.fr; 13th July 2008 at 23:50.
pitch.fr is offline   Reply With Quote
Old 10th July 2008, 17:35   #2  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
an even easier solution would be to input the primaries locations(after calibration) and input them in AVISYNTH :
http://www.avsforum.com/avs-vb/showt...7#post11726737

is that doable ?

here are the primaries locations on my sRGB CRT :
R:[0.658,0.328]; G:[0.334,0.619]; B:[0.150,0.070]

EDIT : another option might be to use ColorMatrix.
but it doesn't support either "REC-601 EBU" or "REC-601 SMPTE-C"

anyhow here's a BT.709>RGB32 conversion(through ffdshow)
+ the same with ColorMatrix(mode="Rec.601->Rec.709") added upfront :





I would say that it looks A LOT better on my sRGB/HDTV calibrated displays

this is a US bluray source btw, so most likely telecined in a "REC-601 SMPTE-C" gamut

hopefully I've convinced a few people now

Last edited by pitch.fr; 10th July 2008 at 18:26.
pitch.fr is offline   Reply With Quote
Old 12th July 2008, 20:01   #3  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by pitch.fr View Post
some ppl have worked on it with PS scripts....but they are confusing "decoding matrix" and "display gamut" :
http://www.avsforum.com/avs-vb/showthread.php?t=912720
It's me who have started the AVSForum thread you refer, and no, I am not confusing "decoding matrix" and "display gamut".

It seems to be you who are confusing "encoding matrix" and "monitoring color gamut". The authoring process being monitored with a different color gamut, does not means that the colors are wrong. They could be correcting the colors on their monitoring displays the same way I suggested in that thread.

All the thread is considering the mastering process is monitored with displays the same color gamut of the encoding matrix; what you are saying is that it's not done that way. In fact, if the above correction in the monitoring displays is not performed, the correction should be a little different, but the math is all there, we just need to adapt it to this situation. I will take a look and update the thread accordingly.

When I started the thread I started using avisynth, but when I realized the correction must be done in the color linear space JohnAd suggested to use pixel shaders and mplayerc.
It seems to be the better option for now, you have it already done and working, why requesting it in avisynth?
yesgrey is offline   Reply With Quote
Old 12th July 2008, 23:46   #4  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
well many people speak about different ways to do it in this thread, sorry I didn't understand it this way

anyhow, great to have you here

tritical is improving ColorMatrix to allow this kind of CIExyz conversions on the fly in AVS/ffdshow

well, for one I only use Haali's Renderer, which is the de facto video renderer on PC to get smooth video....so these PS scripts are not usable.

and ColorMatrix will allow to input the primaries coordinates we get from colorimetry applications, so it will offer tailor-made gamut conversions between SMPTE-C > your own calibrated display for 1:1 colors(no need for an expensive scaler anymore).

well the ISF CEO and many other professionals are showing that the only way to watch bluray with 1:1 colors is to do REC.709 conversion, and watch it on an SMPTE-C gamut if it was mastered in the US, and an EBU gamut if it was done in europe.

these guys are calibrating broadcasting studios with Minolta CS colorimeters all over the world, and they are pushing this new Samsung as the ultimate projector because it supports any kind of gamut you could possibly want

even PLANAR does that now with their newest projectors as well.

you can find above a list with all the bluray that are supposed to be watched on an SMPTE-C gamut.

OTOH, the only thing you need to use this kind of PS script is 2D convolution, that some AVS plugins can do.....only problem is that converting to RGB in AVS is single threaded and very slow compared to ffdshow, and you also get those pesky "chroma upsampling bugs" :
http://forum.doom9.org/showpost.php?...postcount=1868

Last edited by pitch.fr; 13th July 2008 at 15:07.
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 16:35   #5  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
alright, so this PS script is really nice

http://www.avsforum.com/avs-vb/showthread.php?t=912720

...too bad that doesn't work with HR

here's my 19" iiyama CRT calibrated CIE :



here's my XLS script with the primaries coordinates measured with an Eye One Display 2 colorimeter in Color.HCFR :



and here's the correction from SMPTE-C to my CRT gamut, with REC.709 RGB32HQ HD content from ffdshow in VMR9.

left is untouched, right is corrected to match my CRT gamut.







I'd say it removes the green cast on faces(my biggest problem at this point!), and it gives much more natural colors

too bad my red level is now lower, and because it's 8bit/pixel this could possibly introduce banding.

that's also too bad that I've never managed to get good results with Reclock in VMR9......HR is way smoother, so this is not a viable solution for me at this point.

there is some AVS plugins that can do 2D convolution :
http://www.google.com/search?hl=en&q...tnG=Search&lr=

but as I said earlier RGB32 conversion in AVS is slow as hell(not multithreaded and/or optimized), and full of "chroma upsampling bugs".......except if tritical can make miracles happen

otherwise maybe you could create an .icm file ?
or a .cal file to be opened with dispwin.exe(part of ARGYLLCMS www.argyllcms.com) ?

ATi's CLUT is 30bit AFAIK

ARGYLL's coder is very knowledgeable and always willing to help

it's still 8bit/pixel, but better get proper 8bit corrected colors than greenish movies

Last edited by pitch.fr; 13th July 2008 at 21:25.
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 16:44   #6  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
but as I said earlier RGB32 conversion in AVS is slow as hell, and full of "chroma upsampling bugs"
If you feed interlaced material, you need to use
Code:
ConvertToRGB32(interlaced=true)
Wilbert is offline   Reply With Quote
Old 13th July 2008, 16:56   #7  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
ok, thanks for the tip but I've never managed to get RGB32 content out of AVS w/o chroma bugs.

here's a good test sample :
http://forum.doom9.org/showpost.php?...postcount=1868

only HR and ffdshow(with "high quality YV12 to RGB conversion" checked) manage to do bug-free conversions AFAIK...

and HR/ffdshow BT.709 matrixes are also different.....ffdshow's is 1 notch greener, and 1 notch less blue and less red...

Last edited by pitch.fr; 13th July 2008 at 17:02.
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 17:17   #8  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
ok, thanks for the tip but I've never managed to get RGB32 content out of AVS w/o chroma bugs.

here's a good test sample :
http://forum.doom9.org/showpost.php?...postcount=1868
Ok. Post a script and a screenshot which shows these chroma upsampling bugs.
Wilbert is offline   Reply With Quote
Old 13th July 2008, 18:10   #9  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
Quote:
Originally Posted by Wilbert View Post
Ok. Post a script and a screenshot which shows these chroma upsampling bugs.


there is also some AVS commands to increase the chroma upsampling, but that didn't work either.

I'm not an AVS guru, so maybe I'm missing something

what is required is "progressive chroma upsampling", at this point this is not done
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 18:45   #10  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
That's fine and all, but where's the bug you're talking about? There's nothing wrong in your pic.

When converting YUV to RGB, it's a matter of choice if you replicate the subsampled UV planes 1:1, or if you interpolate during resampling. The former is what Avisynth and ffdshow(default) are doing, the latter is what ffdshow's HQ=true does.

Both methods are valid, there is no "right" or "wrong".

Definetly, it is not a bug. A missing option, yes. But not a bug.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 13th July 2008, 19:09   #11  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
oh ok thanks for the clarification Didée...well everyone calls it "chroma upsampling bug" :
http://www.google.com/search?hl=en&q...tnG=Search&lr=

it basically makes the red blocky to hell...and I'm not watching HD to get blocky reds

so is there a way to overcome this issue in AVS ?

I think I read that when you checked "HQ" in ffdshow, it was using some YV12>YUY2 conversion script(from Avisynth actually).....I read it in the ffdshow thread :
http://forum.doom9.org/showpost.php?...postcount=3250

anyhow ConvertToRGB32 can't be multithreaded, so this can't be used in realtime in ffdshow

Last edited by pitch.fr; 13th July 2008 at 19:20.
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 20:16   #12  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
pitch.fr how did you generate that image? Avisynth uses interpolation in its yv12->yuy2->rgb conversions, but the image for converttorgb32() looks more like replication was used. Btw, 'chroma upsampling bug' usually refers to using progressive upsampling for yv12->yuy2 when interlaced is needed or vice versa.

Maybe someone who knows for sure can comment on this, but I was under the assumption that the high quality rgb conversion in ffdshow actually used the yv12->yuy2->rgb conversion code from avisynth, and that the other colorspace conversions in ffdshow used xvid's conversion routines? I took a quick glance at ffdshow-tryout's subversion repository, and saw avisynth's/xvid's conversion code in there, but couldn't quickly see when each was called.
tritical is offline   Reply With Quote
Old 13th July 2008, 20:24   #13  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
hi tritical, did you get my PM ? any chance getting a reply please ?

well I was using Haali's Renderer in MPC, then I pressed the "print screen" key, zoomed to 300% in photoshop and did some cut/paste.

yes it seems that ffdshow is using some YV12>YUY2>RGB32 conversion when you tick the "HQ conversion" option, I dunno why it ends up like that with ConvertToRGB32

anyhow, I'll try to watch a movie with EVR in MPC HC, Reclock and that PS script......but I don't think this will be as smooth as HR in 1920*1080 24Hz
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 20:47   #14  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Yeah, I'll get back to you, gonna go on a bike ride right now though. I quickly downloaded that file, and I get pretty much exactly the same image using ffdshow's hq rgb conversion versus using converttorgb24() in avisynth. image (top is ffdshow default, second is ffdshow hq, third is converttorgb24()) (you might have to zoom in to see the differences). Are you sure that when you tested with converttorgb in avisynth that you didn't accidently still have ffdshow outputting rgb when it decoded the video or something along those lines?
tritical is offline   Reply With Quote
Old 13th July 2008, 21:06   #15  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
I didn't use ConvertToRGB24, only ConvertToRGB32.....as even if I do RGB24 in AVS, then I will need to do convert to 32 again....which will mean more CPU time required

I've just tried again with ConvertToRGB24(matrix="rec709") + RGB24>RGB32 conversion in ffdshow(as neither VMR9/EVR or HR will accept RGB24 input) and I still get pixelated red.....are you sure you got this output from ConvertToRGB24 ?!

maybe it's ffdshow messing the whole stuff up, then ? even tho I kinda doubt it
pitch.fr is offline   Reply With Quote
Old 13th July 2008, 22:14   #16  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
The problem is the color correction must be done in the linear space. So, after you convert from YUV to R'G'B', you must remove gamma and convert it to RGB, apply the color correction, reapply gamma and then output to your screen. This process has a big advantage, you can also perform gamma correction all in the same operation, to apply a gamma to the signal more indicated for your display.

This is not a Convolution 2D, is simply multiplying vectors and matrices. The problem is it being slow, and the PS have the great advantage of being highly multithreaded and all the clip math is already implemented, no cpu work.

I use reclock and it is great. Tell me more about your problems, maybe I can help you.

When I created that thread, I asked Haali to add that PS funcionallity to HR, since he is already using PS for the YUV->RGB conversion. He told me he would look into it, but never replyed me again about the subject, so I think he did not approve the idea... Let's keep using mplayerc and vmr9...
yesgrey is offline   Reply With Quote
Old 13th July 2008, 23:03   #17  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@pitch.fr
Something is wrong in your chain. Here is how I tested:

1.) ffdshow default. Use directshowsource("Bronz_s.mkv") in avisynth to open the mkv file using ffdshow, and set ffdshow to output RGB w/o hq conversion. Open in vdub.
2.) ffdshow hq. Same as method 1 setup, but check the hq rgb conversion box in ffdshow.
3.) avisynth conversion. Again use directshowsource, but make sure ffdshow is set to output YV12 (check that it is in vdub), and use converttorgb24 or converttorgb32 after directshowsource() in the avisynth script.

Using this, I get that 2 and 3 give almost identical output (image).
tritical is offline   Reply With Quote
Old 13th July 2008, 23:08   #18  |  Link
pitch.fr
Didée 4 President
 
Join Date: Jun 2008
Posts: 239
Quote:
Originally Posted by yesgrey3 View Post
Let's keep using mplayerc and vmr9...
yeah, except if tritical can make some highly multithreaded and optimized code, I don't see it working in realtime in ffdshow

anyhow, I've just run through all my test movies on my DLP projector.

I'd say the colors look way more realistic

the best example being an HD bollywood movie, where red clothes look too dark, dull and artificial and skin tones slightly too green.....and when I enable the tailor-made PS script, bam! it looks natural (again)

well my main issue with not using HR w/ Reclock is that it's simply not as smooth.....HR is just so smooth, that's quite amazing...

I can watch a 2H movie in 24fps@24Hz with very low jitter and no dropped frame.

EVR or VMR9 can't offer me this kind of super low jitter.

but I'll run more tests, considering I'm starting to enjoy getting 1:1 colors on a 2 meters wide projection screen

Quote:
Originally Posted by tritical View Post
@pitch.fr
Something is wrong in your chain. Here is how I tested:

1.) ffdshow default. Use directshowsource("Bronz_s.mkv") in avisynth to open the mkv file using ffdshow, and set ffdshow to output RGB w/o hq conversion. Open in vdub.
2.) ffdshow hq. Same as method 1 setup, but check the hq rgb conversion box in ffdshow.
3.) avisynth conversion. Again use directshowsource, but make sure ffdshow is set to output YV12 (check that it is in vdub), and use converttorgb24 or converttorgb32 after directshowsource() in the avisynth script.

Using this, I get that 2 and 3 give almost identical output (image).
that's really weird ?! I'll run more tests tomorrow ?!

and could you do that gamut conversion in 10 bit in AVS(even if it's not officially supported yet) ?

Last edited by pitch.fr; 13th July 2008 at 23:16.
pitch.fr is offline   Reply With Quote
Old 14th July 2008, 00:03   #19  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by pitch.fr View Post
yeah, except if tritical can make some highly multithreaded and optimized code, I don't see it working in realtime in ffdshow
It would be great if the gpu drivers could allow this. It would be so simple to them, but I don't believe they would do this kind of stuff to just a few guys...

Quote:
Originally Posted by pitch.fr View Post
I'm starting to enjoy getting 1:1 colors on a 2 meters wide projection screen
I understand you. My projector is a bit old (JVC M15), and the green is slightly off. It never bothered me. In fact, I never noticed it. After starting using mplayerc with the PS for correcting the colors, I started noticing and prefering the standard colors...
yesgrey is offline   Reply With Quote
Old 14th July 2008, 00:09   #20  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by pitch.fr View Post
and could you do that gamut conversion in 10 bit in AVS(even if it's not officially supported yet) ?
For this the PS is better. I think it operates with more than 14 bit precision. But the biggest problem is we not having bit depths higher than 8 bit per color in the pc world. Due to this, in theory, you could get some banding with the color correction, in practice, I never noticed it.
yesgrey is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.