PDA

View Full Version : Question re: 10&12 bit color


t_2
25th December 2003, 19:47
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

mf
25th December 2003, 19:57
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?

t_2
25th December 2003, 20:12
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
25th December 2003, 22:13
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?

PaulKroll
26th December 2003, 00:56
Is there a standard for mpeg2 using 10 bit/color/pixel colorspace? I thought all mpeg2 was yv12, effectively "8 bit" (or less) color.

morsa
26th December 2003, 01:33
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.

sh0dan
26th December 2003, 12:15
I'm sorry - most of you are wrong. :rolleyes:

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.

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 (http://www.devx.com/amd/Article/17783).

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

t_2
26th December 2003, 15:53
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

PaulKroll
26th December 2003, 16:58
T_2: No. :)

That AviSynth:ForkingAround (http://www.avisynth.org/index.php?page=ForkingAround) page which links to the AviSynth:WhyPython (http://www.avisynth.org/index.php?page=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 (http://python.org/) 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. :)

Bidoche
27th December 2003, 11:52
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.

geoffwa
6th January 2004, 16:14
WhyPython (http://www.avisynth.org/index.php?page=WhyPython) is the best troll I've read in quite a while!

Cheers!

unplugged
17th January 2004, 00:17
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.

Bidoche
18th January 2004, 23:57
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.

unplugged
19th January 2004, 14:23
15-bit bpc, what does the free bit do?

Bidoche
20th January 2004, 00:30
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)

MfA
20th January 2004, 03:24
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?)

Bidoche
20th January 2004, 08:36
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 ?

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...

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.

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.

sh0dan
20th January 2004, 09:15
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

MfA
20th January 2004, 11:03
Bidoche, I just meant you could use operator overloading tricks to perform automatic conversions.

Shodan, so basically no overbright ... why not?

Bidoche
20th January 2004, 11:36
@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

sh0dan
20th January 2004, 19:44
@Bidoche: Of course :) Just wanted to show the principle. In the real world I would always have used bitshifts! :)

btw, it should be:

15bpc = (unsigned short)8bpc*128
8bpc = (unsigned char)(15bpc+63)/128

PS. I also know the cast is wrong - if you want it as it should look in the real world:

unsigned short fifteen = (unsigned short)eight<<7;
unsigned char eight = (unsigned char)((fifteen+63)>>7);

Bidoche
21st January 2004, 13:11
It depends if you see it as an interpolation or as a change of precision.

interpolation:
15bpc = 8bpc*128 + 63 ( was (8bpc + 1/2)*128 - 1/2 )
8bpc = 15bpc/128 ( was (15bpc + 1/2)/128 - 1/2 )

precision change:
15bpc = 8bpc*128
8bpc = (15bpc + 63)/128


Personally, I like interpolation better, it doesn't overflow and it's symetrical in 0-255

sh0dan
21st January 2004, 13:41
Could you please explaing to me once more, why it is a good thing that luma = 0 in 8bpc is set to be luma = 128 in 15bpp?

Bidoche
21st January 2004, 20:03
It's not a good thing, ideally you would have 0 -> 0.
But you'd have 255 -> 32767 too.
Since we can't have a true 32767/255 multiplication, we use an approximate function.

x |-> 128*x is accurate for small x, but the error rises up to 127 for x = 255 (32767 - 255*128 = 127)

x |-> 128*x + 63 yields an maximum absolute error of 64


Conceptually the 0 side is not special versus the 255 side, so it should be better to handle them symetrically.

Doing that, we will have (8bpc -> 15bpc)(reverse luma) = (reverse luma)(8bpc -> 15bpc) which is a result one would probably expect.

MfA
21st January 2004, 22:59
You want to have 0 = 0 because there are lots of functions which assume the origin is 0, such as a gamma curve for instance ... I see no simular type of reasoning to want 255 to map to the maximum possible value, just wanting to use the range efficiently doesnt quite cut it IMO.

BTW I still dont understand why the MSB has to be 0, you can do the math with 32 bits anyway (it's just as fast, unless you want to use SIMD-in-integer tricks ... but you might as well use real SIMD then). Which seems to leave plenty of bits to detect under/overflow right?

sh0dan
22nd January 2004, 13:16
@bidoche - I see your point. I does make sense.

I'm however getting doubts about how usable it would be.

- No defined YUV format support > 8bpc. (?)
- All encoders end up with 8bpc.
- Most NLE-apps use RGB anyway.

I see no real gain from >8bpc, as the material in all cases would have to be converted to either 8bpc or RGB.

I do however think that it is a good idea to include a possibility for support in 3.0, if the need should arise.

morsa
22nd January 2004, 22:59
Donīt think only in terms of encoding.Think about Avisynth as a powerfull filtering machine.It could even be used as a restoration system for 2k and higher resolutions material.

unplugged
22nd January 2004, 23:47
Originally posted by sh0dan
I'm however getting doubts about how usable it would be.
I see no real gain from >8bpc, as the material in all cases would have to be converted to either 8bpc or RGB.
Excuse me, but I'm quite surprised by your doubts

The more bits are important and only important at (multi)filtering stage, the fact that they will further downmixed to 8-bpc (and I have always assumed this) doesn't mean that the subprecision is useless.
In our 15-bpc case the new 7 bits represents a valid accumulator that stacks and compensates continuously those fractions that, in 8-bpc mode, become roundings and sum noise at each pass.
The common side effect of multi-pass filtering in 8-bpc mode is less dynamics and more posterization, the more are the passes less is the sense of original image sharpness.

One other idea to add may be the possibility to perform, at end of 16-bpc scripts, a 16-to-8 bpc downmix using the color dithering approach. ;)

P.S.: Of course for simple or ordinary avisynth scripts 8 or 16 bpc doesn't do difference.

sh0dan
23rd January 2004, 17:16
Originally posted by unplugged
One other idea to add may be the possibility to perform, at end of 16-bpc scripts, a 16-to-8 bpc downmix using the color dithering approach. ;)

... but is it worth spending half a year rewriting all filters to support this. IMO at the current stage the gain is too small compared to the time actually needed for this task.

I can find a lot of more important issues to adress in the same timeframe.

However - adding the possibility of 15bpc to AviSynth 3.0 is definately a good idea, even though it might be very sparsely supported.

unplugged
23rd January 2004, 21:21
No no, rewriting all... no, sure nobody that know what mean this could ask to you such pain work! :p
Assembly and its optimization is brain torture, I know.

But good is if avisynth team would give a small implementation from time to time.

The scenario for 15-bpc may will be interesting for certain things, for example we can perform YUV->RGB and RGB->YUV combined operations losslessly (considering orginal 8-bpc sources), thus programmers may concentrate to RGB filters implementation (or a least one of...) considering that several effects and manipulations are better known or better performed with RGB colorspace. (think NLE case)

These are ideas, I'm not a skilled programmer. :)

Bidoche
27th January 2004, 22:40
Originally posted by sh0dan
However - adding the possibility of 15bpc to AviSynth 3.0 is definately a good idea, even though it might be very sparsely supported.Not a problem, adding a color space in 3.0 is just the matter of a few lines of code. (another ColorSpace subclass and some virtual functions definitions)
Of course that don't make it supported by filters, except basic ones (like Crop, Trim).

Bidoche
30th January 2004, 09:21
It's now done.
Besides YV24 which I had already made before, I added YV45, RGB45 and RGB60.

Code submissions are welcome. :)

Bidoche
31st January 2004, 11:23
I have started making the interpolation code for the trivial colorspace conversions (Depth8 to Depth15 and back) in assembly.
But besides that and the Resize filter code, since I am working on that and it's not really different, I won't do more at the time being.


@sh0dan

Btw, since I am talking about Resize(Horizontal, Vertical), I would like your input about the code modifications I made.
Not to check if my code is right, but rather if I am right thinking my patterns mods may prove it to be faster.

Let me explain with the planar case:

original pattern used:
offset0|offset1|c0a|c0b|c1a|c1b|...|offset2|offset3|...

pattern I use: (for this case)
offset0|offset1|offset2|offset3|c0a|c0b|c0c|c0d|c1a|c1b|c1c|c1d|c2a|c2b|c2c|c2d|c3a|c3b|c3c|c3d|...

It make it easier to work on 4 pixels by xloop, and to consume 4 coeffs (per pixel) per aloop, ie 16 coeffs per aloop.
Even you dynamic code only consumes 12 coeffs per aloop.

I haven't committed the code yet, but I can if you want to see it, or attach it here.

Edit: corrected a stupid error in the pattern layouts

shlezman
8th February 2004, 14:53
Why not using signed pixel-format, biased to 0 (8bpp-128)*256 for daisy-chained filters and for high-depth pixel format ?
a high precision is achieved
wider pixel range with negative results allowes smater filters
conversion from/to display/coding range/format will be very simple
SIMD will be simple to use

sh0dan
8th February 2004, 15:55
Originally posted by Bidoche
It's now done.
Besides YV24 which I had already made before, I added YV45, RGB45 and RGB60.

What is RGB60 for?

I certainly don't hope it is for alpha. Having invisible alpha channels is something I hoped was killed for 3.0?

Bidoche
8th February 2004, 16:59
Just when I arrived at the same conclusion... about RGB45 !
I mean, who would want to use a misaligned format when one aligned is available, once established memory use is not the issue...

Here lies my answer, I made it for alignment purpose.

But now that you pointed it to me, I see that I misnamed it, 60 implies there are 60 bits significative, which is not the case...

So there should be only RGB45, but with 8 bytes sample alignment (I guess you would agree on that).

t_2
9th February 2004, 07:58
It's been a long time since I actually understood what you developers are talking about here, but this caught my attention:

Quote from Sh0dan: "I certainly don't hope it is for alpha. Having invisible alpha channels is something I hoped was killed for 3.0?"

Does this mean that there won't be alpha support in 3.0, or does it mean that there is a better way to do alpha than having a separate alpha channel??

@Sh0dan: I really like the new MMXed Dissolve in 2.54. (Of course FadeIn and FadeOut are also affected) It is so much faster. Now with ReduceBy2 after the Source filter you can edit anything in real time on most P4s. Very powerful NLE!

Richard Berg
9th February 2004, 08:10
Does this mean that there won't be alpha support in 3.0, or does it mean that there is a better way to do alpha than having a separate alpha channel??
It's much nicer to give a mask its own (YV12) clip. Then you can do all your mask operations with standard Avisynth commands, and pass the result when ready to Overlay as a 3rd argument. So long as it's possible to extract traditional RGBA masks into clips and/or insert them back (ShowMask and Mask, respectively), there's no reason to focus on hidden alpha channels anymore.

t_2
9th February 2004, 08:52
Ok

sh0dan
9th February 2004, 09:24
Originally posted by t_2
Does this mean that there won't be alpha support in 3.0, or does it mean that there is a better way to do alpha than having a separate alpha channel??
Overlay uses luma, or greyscale RGB for masks, which IMHO is the most userfriendly way of handling alpha. Having an invisible component, is just a mess. Many filters doesn't support RGB32 alpha properly anyway.

Richard Berg
9th February 2004, 20:23
ShowMask and Mask, respectively
err, make that ShowAlpha and Mask :rolleyes: