Previous topicNext topic

10-bit Magic window?

Suggestions for new features for Magic.
Post Reply
pinmode
Posts: 44
Joined: Sun May 29, 2016 7:39 pm

10-bit Magic window?

Post by pinmode »

Correct me if I'm wrong but it seems like the Magic window is 8-bit when using the VideoFile module, even if the source video is 10-bit. Assuming that's correct, is it possible to build in a 10-bit option? It helps with banding problems.
Terry Payman
Posts: 710
Joined: Sun Sep 14, 2014 8:15 am
Location: UK
Contact:

Re: 10-bit Magic window?

Post by Terry Payman »

I would also like to be able to render 10-bits per channel to output files, even if not to display in real time - although that would have been be ideal on a recent video shoot where I used an external hardware recorder to capture effects from a live video feed. The recording format was 10-bit ProRes 4:2:2, so it's a pity that the bottom two bits were unused.

For effects footage supplied to video editors 10-bit depth would give much more adjustment freedom before the image "breaks up".

I would not mind if it needed four times the GPU memory.
blackdot
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: 10-bit Magic window?

Post by blackdot »

whats the benefit of those addituonal 2 bits?
Terry Payman
Posts: 710
Joined: Sun Sep 14, 2014 8:15 am
Location: UK
Contact:

Re: 10-bit Magic window?

Post by Terry Payman »

A smooth gradient will be rendered with greater precision; the intensity quantisation steps between adjacent values will be one quarter of the size with 10-bit rather than 8-bit. Over a given distance along the gradient there will be four times as many steps, of one quarter the intensity change.

The steps can become visible, especially if subsequent processing effectively amplifies the signal. This is "banding", and can look very bad.
If the input video has been lossily compressed (eg from an mp4 file) then the banding looks worse still, as blocking artifacts make the banding irregular which looks even worse than the simple contour lines seen on synthesised images.

10-bit (even 12-bit) video is extensively used in film making to avoid subsequent banding problems when grading the images to give the desired look.
Attachments
Compression banding on video - Credit: Philp Bloom
Compression banding on video - Credit: Philp Bloom
Compression banding on video.jpg (19.56 KiB) Viewed 8982 times
Quantisation banding on synthetic image
Quantisation banding on synthetic image
banding.jpg (9.64 KiB) Viewed 8982 times
blackdot
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: 10-bit Magic window?

Post by blackdot »

thanks for the explanation, makes sense of course. those 10 instead of 8 are per channel? or is this something entirely different than the rgb(a)-thing, each with 8bit depth?

sorry, i dont want to derail the thread, point me in the direction and i'll do my own research :).
Terry Payman
Posts: 710
Joined: Sun Sep 14, 2014 8:15 am
Location: UK
Contact:

Re: 10-bit Magic window?

Post by Terry Payman »

Yes, 10 bits per channel.
Magic
Site Admin
Posts: 3440
Joined: Wed Apr 09, 2014 9:28 pm

Re: 10-bit Magic window?

Post by Magic »

Having greater internal precision in Magic is certainly a possibility for the future. In fact, Magic's ISF functionality already supports it, and some of the ISF effects use 32 bits/channel (meaning 32 * 4 = 128 bits/pixel) specifically to avoid quantization errors.

Regarding "10-bit video", keep in mind that it's still only 32 bits/pixel. Instead of the 32 bits being divided 8/8/8/8 as in standard RGBA, they are divided 10/10/10/2, which gives greater precision to the color, but much less to the alpha. This would be insufficient for any uncompressed internal processing Magic does relating to alpha. Magic would need at least 16/16/16/16 (= 64 bits/pixel) to maintain the precision, because the total bits/pixel must be a power of 2. Thus, as Terry mentioned, twice the video memory would be needed for 16 bits/channel, and four times would be needed for 32 bits/channel.

When I revisit the issue of Magic's export formats (primarily to support more codecs and higher resolutions), I'll make sure to keep the bit depth in mind. But just be aware it will require a lot of time and effort to make absolutely everything in Magic support higher bit depths -- it is not a simple matter of "flipping a switch" :). Also, the primary goal of Magic will always be to process graphics in real-time, which is much faster for 8 bits/channel than anything higher.
Terry Payman
Posts: 710
Joined: Sun Sep 14, 2014 8:15 am
Location: UK
Contact:

Re: 10-bit Magic window?

Post by Terry Payman »

Eric wrote:Having greater internal precision in Magic is certainly a possibility for the future.
Yay :D
Eric wrote:...some of the ISF effects use 32 bits/channel (meaning 32 * 4 = 128 bits/pixel) specifically to avoid quantization errors...
Wow :D I didn't realise this. Please name some ISF examples - useful as a guide in my quest to write the "perfect" video feedback module.
Eric wrote:...When I revisit the issue of Magic's export formats ... I'll make sure to keep the bit depth in mind. ...
Yay :D
Eric wrote: But just be aware it will require a lot of time and effort to make absolutely everything in Magic support higher bit depths ...
I think the combination of 32 bits/channel ISF for the final stage(s) of Magic processing and deeper export bit depth would give me a significant improvement in quality even if other internal modules remain 8 bits/channel.

I'm anticipating that 32 bits/channel blur and 32 bits/channel trails could be used to "smooth" any problematic paths in the processing chain that were 8 bits/channel. Perhaps everything I need would be enabled with a simple ( ;) ) 16-bit per channel option on the .png export, and merely ( ;) ) widening internal data paths with no other changes needed to the present Magic.

With regards to handling 10-bit video, 16-bit per channel .png option for a VideoFile input would be really neat too.
Eric wrote: ...the primary goal of Magic will always be to process graphics in real-time, which is much faster for 8 bits/channel than anything higher.
If ISFs can provide the deeper processing then the user would be free to choose the speed tradeoff options. The native Magic modules could remain 8 bits/channel for optimum speed, and the inherently extensible ISF library could provide any missing functionality for specialised high-bit-depth requirements.

As a final thought maybe it's not too difficult to consider deep colour GPU output for live use.
Magic
Site Admin
Posts: 3440
Joined: Wed Apr 09, 2014 9:28 pm

Re: 10-bit Magic window?

Post by Magic »

Please name some ISF examples - useful as a guide in my quest to write the "perfect" video feedback module.
Check out VVMotionBlur 3.0, which is a type of feedback effect. What makes it extra smooth is marking the first internal pass as "FLOAT": true.

For more info you can have a look at https://www.interactiveshaderformat.com/spec, specifically the PASSES key section and then the FLOAT key subsection, which talks about 32-bit precision.
Terry Payman
Posts: 710
Joined: Sun Sep 14, 2014 8:15 am
Location: UK
Contact:

Re: 10-bit Magic window?

Post by Terry Payman »

Many thanks Eric - that's helpful.
pinmode
Posts: 44
Joined: Sun May 29, 2016 7:39 pm

Re: 10-bit Magic window?

Post by pinmode »

Just catching up here - thanks Eric!
Post Reply