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 Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th December 2003, 19:47   #1  |  Link
t_2
Registered User
 
Join Date: Apr 2003
Location: USA
Posts: 91
Question re: 10&12 bit color

Teach AV in Europe to high schoolers, and always rave about AVISynth. I tell them it is much more powerful than Premier. OK, Premire is more user friendly, but I love editing DV in AVISynth/VirtualDubMod and it's easy, powerful, and often/usually has better quality filters than Premire.

Imagine my dismay when I learned that Premire Pro does 10 bit color and AVIsynth doesn't. OK, no program does everything, but with native 64 bit processors already on the market 10 bit color seems to be on the way (or already here as in the case of Premire Pro)

Question1: Am I correct in my assumption that AVISynth does not currently support 10 bit color?

Queston2: Just for the sake of curiosity, -well not really, because I have dreams about filming HD and using AVISynth to edit off line - would it be hard to give it 10 bit support, at least initally in some filters like resize, dissolve, trim, levels, tweak???

Thanks,
t_2
t_2 is offline   Reply With Quote
Old 25th December 2003, 19:57   #2  |  Link
mf
·
 
mf's Avatar
 
Join Date: Jan 2002
Posts: 1,729
Erhm... AVISynth uses either 12, 16, 24 or 32 bit color. The colorspaces using those bpps would be:
12: YV12
16: YUY2
24: RGB24
32: RGB32

What colorspace uses 10 bit and why do you think AVISynth should support it?
mf is offline   Reply With Quote
Old 25th December 2003, 20:12   #3  |  Link
t_2
Registered User
 
Join Date: Apr 2003
Location: USA
Posts: 91
Wow, that was quick! Sorry, what I mean is 10+10+10 =30bit w/o alpha. I have seen RGB24 refered to as 8 bit color because each of the primary colors gets 8 bits.

JVC's very new(apparently not yet for sale) CMOS based HD box camera outputs raw HD-SDI at 10 bits per color channel. I would like to use a PCI based encoder card to caputure in MPEG2 at about 100Mb/sec.

More about this here:

http://forum.doom9.org/showthread.php?s=&threadid=67095
t_2 is offline   Reply With Quote
Old 25th December 2003, 22:13   #4  |  Link
t_2
Registered User
 
Join Date: Apr 2003
Location: USA
Posts: 91
While I'm at it, here is a real curiosity question:

How hard would it be to compile/produce a native 64 bit version of AVISynth to take advantage of the new Athlon64?
t_2 is offline   Reply With Quote
Old 26th December 2003, 00:56   #5  |  Link
PaulKroll
Registered User
 
Join Date: Nov 2002
Location: Illinois
Posts: 13
Is there a standard for mpeg2 using 10 bit/color/pixel colorspace? I thought all mpeg2 was yv12, effectively "8 bit" (or less) color.

Last edited by PaulKroll; 26th December 2003 at 00:59.
PaulKroll is offline   Reply With Quote
Old 26th December 2003, 01:33   #6  |  Link
morsa
the dumbest
 
Join Date: Oct 2002
Location: Malvinas
Posts: 494
Mpeg2 supports YUV2 and 10 bit per color channel.
Think about it now that Radeon supports also 10 bit per color channel and a 10 bpcc has been proposed for the DVCPRO format.Also BetaDigi works in 10 bit and the new HDCAM SR.Everything is going to 10 bits per color channel.
The new big format TFT also supports 10 bit color channel because the bigger you go the more you notice 8 bit per color channel banding arctifacts.

Last edited by morsa; 26th December 2003 at 01:55.
morsa is offline   Reply With Quote
Old 26th December 2003, 12:15   #7  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
I'm sorry - most of you are wrong.

AviSynth ONLY supports 8 bits per channel (since there are more channels that usually adds up to more bits per pixel).

MPEG2 has up to 10 bit per DC component. That means 10 bit is used on the DCT-transformed information.

I personally don't view AviSynth as an alternative to expensive NLE-packages - more as a supplement. I personally use AviSynth before importing the video into Premiere/After Effects, and when I'm done editing the video for smaller adjustments. Cutting out 10 seconds of material is far easier in AviSynth than having to render/export the entire project once more.

Even though speed is a main feature of AviSynth, Quality is NOT secondary. However more than 8bpc is only needed when doing multiple layers and compositing. You gain nothing by editing your DV-material in 10bpc. If you are doing advanced compositing, you might run into aliasing problems with many semitransparent layers. But AviSynth isn't a compositing application.

With that being said, we are talking about a 15bit per channel mode in AviSynth 3.0.

Quote:
Originally posted by t_2
How hard would it be to compile/produce a native 64 bit version of AVISynth to take advantage of the new Athlon64?
Depressingly hard:

1) MMX is NOT supported in pure 64bit mode. Most optimized code would have to be rewritten as SSE2 code.

2) inline assember is NOT supported in Microsofts AMD64-bit version. Most assembler (close to everything) in AviSynth is written as inline assembler.

More information on porting to AMD 64 here.

As Avisynth 3.0 is a complete rewrite, there is a chance that 64-bit AMD64 will be one of the supported platforms
__________________
Regards, sh0dan // VoxPod

Last edited by sh0dan; 26th December 2003 at 12:35.
sh0dan is offline   Reply With Quote
Old 26th December 2003, 15:53   #8  |  Link
t_2
Registered User
 
Join Date: Apr 2003
Location: USA
Posts: 91
Quote of sorts "Not a replacement for expensive NLE programs" Hummm.

OK, I use Premire too, but can't get excited about it the way my AV students do. AVISynth is so much better, and it fits several times over on a floppy! Just try putting Premire on a floppy several times over and see what happens!

Here in Central Europe you see two things, unabashed piracy and people who really can't afford software or multimedia content(CDs &DVDs). For them AVISynth is a million times better than Premire, because it's free/i.e., affordable and it does the job (better?

Of course, its one thing to rant about it, and another thing to develop it day in and day out year after year. That requires real devotion, not just lip service! (lip service, because sorry to say haven't yet backed up my enthusiasm with my pocketbook)But then again, perhaps we do help the cause because even though it costs us dearly to produce, we do release our humble content for free to one and all.

Summing up, I like to think of it the other way around, Premire as a suplement to AVISynth. It's not exactly the same thing as this joke explains:

"One day while on silent retreat a young seminarian was pacing back 'n forth in the Church and smoking all the while, another seminarian came up to him and reproached him, saying: "How dare you smoke on retreat!" To which the first said, "I got permission from the retreat master." "I can't believe he allowed you so smoke while you are praying." "He didn't, I asked him if I could pray while I was smoking!"

Now for a final question which I really shouldn't be asking, because besides being another trip down curiosity lane, I doubt that I really would understand the answer, but here goes.

@ www.avisynth.org there is a link called "forking around" There somebody seems to be stating that AviSynth isn't just a ripper tool, it is a full fledged NLE in its own right and then goes on to talk about something called python that would somehow make AVISynth independent of platforms, COLOR DEPTH and OSes. Could this Python thing figure into AVISynth 3?

t_2
t_2 is offline   Reply With Quote
Old 26th December 2003, 16:58   #9  |  Link
PaulKroll
Registered User
 
Join Date: Nov 2002
Location: Illinois
Posts: 13
T_2: No.

That AviSynth:ForkingAround page which links to the AviSynth:WhyPython page is pretty obviously by a Python and Linux advocate. As a piece of advocacy, it's OK I guess, but there are some very odd claims and pontifications on those pages.

Python is a computer language, generally used for scripting. Moving AviSynth to be all Python is probably impossible and definitely impractical: Python can be very fast at some things, but handling of video isn't one of them. And the idea that moving the code to Python would solve the inter-machine problems is naive: much of the problem with running AviSynth or VirtualDub(Mod) under Linux or Mac is not language-dependant, but fundamental infrastructure-dependant. Those OSes just handle video differently than Windows machines do.

As an NLE, I think AviSynth is just the wrong tool. Even VirtualDub(Mod)'s simple cutting/pasting is considerably better for actual editing. AviSynth excels at automating processing, which CAN include some editing, but it's the wrong tool for editing a whole film. It's the right tool for processing a scene (to lighten or darken or smooth or whatever) or a whole film (resize, crop) or for certain special effects. That's what it's meant for, and it does those things really well.
PaulKroll is offline   Reply With Quote
Old 27th December 2003, 11:52   #10  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
About color depth :

10 bits allows to pack a pixel in an int (thus restoring RGB24 lacking alignment).
But in the order hand, its processing is likely to be quite slow, since it needs constant bit manipulations...
So there won't be 10 bits depth ever, but you may have 16 (15 to avoid int overflow issues) someday.
Actually I just need someone to state he will make filter code for RGB48 and/or YV888 (just invented the names) and I will make the colorspace available.


About AMD64:

I guess I could have 3.0 support it, branching filters to specific subclasses as needed.
But all the asm code needing to be rewritten still need to be rewritten...


About Python:

The point is not to make Avisynth all python (impossible), but to allow filter chain creation/manipulation through Python.
That would be an entry point to avisynth for apps without having to directly interface with it.
Anyway it's far from being on the TODO list at the time being.


About portability:

Avisynth does not care how OSes handle video, since avisynth handles video as avisynth does, and not as they does.
Avisynth is not tightly bound to Windows, it imports/exports video through VFW/COM but it only affects AVISource/DirectShowSource (and the trick so .avs pass in mplayer)
It will probablt not that hard to have the equivalent done for Linux or others...

What it is bound to is VC++, since there are hundreds and hundreds of lines of inline asm which he is the only one able to compile.
Bidoche is offline   Reply With Quote
Old 6th January 2004, 16:14   #11  |  Link
geoffwa
Level 3 Pirate
 
Join Date: Mar 2002
Posts: 45
WhyPython is the best troll I've read in quite a while!

Cheers!
geoffwa is offline   Reply With Quote
Old 17th January 2004, 00:17   #12  |  Link
unplugged
Registered User
 
unplugged's Avatar
 
Join Date: Oct 2001
Location: Italia
Posts: 412
Quote:
Originally posted by sh0dan
Even though speed is a main feature of AviSynth, Quality is NOT secondary. However more than 8bpc is only needed when doing multiple layers and compositing. You gain nothing by editing your DV-material in 10bpc. If you are doing advanced compositing, you might run into aliasing problems with many semitransparent layers. But AviSynth isn't a compositing application.
I always wondered if I needed a special 16-bpc Avisynth version (and plugins) especially for certain massive scripts.

In my experience the need of more sampling bits per sample in processing applications ( in this case >8 ), wether for image or sound, is really true when we start to apply multiple filtering, otherwise when can't obtain a refined output.
So IMO multi-layer support isn't the main pretext.
Often I see this limit in my avisynth scripts when combine just few filters, the result is almost always a noticeable cut in image dynamics.
The dynamics is always the first thing that goes wasted (posterization like effects...).

For ex. filters like Blur and Sharpen used jointly with others (smoothers...) reduce drastically the dynamics with the standard 8-bit per component buffer.
unplugged is offline   Reply With Quote
Old 18th January 2004, 23:57   #13  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
As I already stated, if you (or anybody else) feel like coding 15 bits depth (15, not 16) versions of filters, please do so.
And I will include it in 3.0.
Bidoche is offline   Reply With Quote
Old 19th January 2004, 14:23   #14  |  Link
unplugged
Registered User
 
unplugged's Avatar
 
Join Date: Oct 2001
Location: Italia
Posts: 412
15-bit bpc, what does the free bit do?
unplugged is offline   Reply With Quote
Old 20th January 2004, 00:30   #15  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
If I understodd sh0dan explanations correctly, MMX DO want the 16th bit to be a sign bit (when we don't).
So we just have to give up this one. (or not use MMX)
Bidoche is offline   Reply With Quote
Old 20th January 2004, 03:24   #16  |  Link
MfA
Registered User
 
Join Date: Mar 2002
Posts: 1,075
Ditching MMX? It would seem more natural to ditch non saturated integer coding ... but if people really want, they can twiddle the bits and convert it to a 15 bit representation before doing calculations without too much overhead.

How about just using the 16 bit format, and including some new C++ types to make working with it without MMX a little easier? A matrix type which presents it as floats, and a 16 bit type with saturation for experimentation? (For when you know you will want to convert the filter to MMX once it is done.)

BTW how many fractional bits were you thinking of? (ie. leave room for overbright or not?)

Last edited by MfA; 20th January 2004 at 05:47.
MfA is offline   Reply With Quote
Old 20th January 2004, 08:36   #17  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Quote:
they can twiddle the bits and convert it to a 15 bit representation before doing calculations without too much overhead.
You mean convert to 15 bits ina buffer every time the need arises.
I guess we could do that, but is the 16th bit really worth the hassle ?

Quote:
How about just using the 16 bit format, and including some new C++ types to make working with it without MMX a little easier?
A C++ type won't help coding Assembly path, and the C++ path already don't care about MMX...

Quote:
A matrix type which presents it as floats, and a 16 bit type with saturation for experimentation? (For when you know you will want to convert the filter to MMX once it is done.)
Don't follow you.

Quote:
BTW how many fractional bits were you thinking of? (ie. leave room for overbright or not?)
I don't know, sh0dan said once in some thread that it would be 15 bits and not 16, and I trust him on that.
But he did not give any details.
Bidoche is offline   Reply With Quote
Old 20th January 2004, 09:15   #18  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
BPC: 16.
Range: 0 -> 32767. (15 active bits)
Last bit (bit 16): Must always be 0.
Overbright/Superblack: There will be a 7 bit fraction compared to standard YUV. This means that:

15bpc = (unsigned short)8bpc*128
8bpc = (unsigned char)15bpc/128
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 20th January 2004, 11:03   #19  |  Link
MfA
Registered User
 
Join Date: Mar 2002
Posts: 1,075
Bidoche, I just meant you could use operator overloading tricks to perform automatic conversions.

Shodan, so basically no overbright ... why not?
MfA is offline   Reply With Quote
Old 20th January 2004, 11:36   #20  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
@MfA

Can you produce some code as a proof of concept ?
I fail to see if it will be really useful.


@sh0dan

No FP rounder ?
There are everywhere elsewhere.

I'd more likely see:

15bpc = (unsigned short)8bpc*128 + 63
8bpc = (unsigned char)15bpc/128
Bidoche 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 16:04.


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