Output more than 8 bit of colour information if the colourspace supports it

[GoogleCodeExporter]

What steps will reproduce the problem?
about any ASS script with an animated transform from one colour to another one

Please provide any additional information below.

I do realize that most subtitle lines in ASS subtitles won't need a higher 
bitdepth, since their colours are only defined in 8 bit RGB to begin with. 
However, I assume that the conversion to a YUV colourspace would benefit from a 
higher bitdepth result being overlaid onto the picture, which I assume is 
already built in.
I propose that a similar mechanism be implemented for transforms that actually 
benefit from a higher bitdepth being used also in RGB, and for some of the 
VSFilterMod tags if those are ever to be implemented.
One example for such a transform would be changing the colour of the subtitles 
from one colour to another over a limited time. Another example would be the 
colour gradient tag in VSFilterMod. Generally, a logical next step would be to 
increase the bitdepth of the alpha-channel as well when necessary, which might 
prove useful in e.g. fades.
I attached a file that, as I believe shows several examples that could benefit 
from such behaviour.
Also, regarding Issue #40, since I believe madVR's internal processing bitdepth 
is 16 bit, it might be a good idea to support outputting a higher bitdepth 
through this interface as well, especially if the subtitle renderer itself is 
to perform some sort of colour correction. However, since the interface is 
supposed to be generally useable and not be tied to madVR, it may be necessary 
to implement some sort of fallback logic that automatically switches back to 8 
bit RGB if the renderer doesn't support the high bitdepth RGB input.

If such behaviour is already implemented (or planned), I apologize for the 
trouble I caused.

Original issue reported on code.google.com by TheDarkS...@gmail.com on 17 Apr 2012 at 10:22

Attachments:

• example.ass

[GoogleCodeExporter]

Original comment by cyber.sp...@gmail.com on 6 May 2012 at 4:45

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I apologize, but I just now realized that maybe I should have been clearer 
(maybe it was clear to begin with, in this case feel free to delete this [then 
useless] comment of mine):
For the following, I will, for the sake of simplicity (I wouldn't know how to 
explain it properly otherwise), assume that xy-VSFilter but always has to 
create an RGB image and then convert it to YUV, disregarding the fact that it 
can, contrary to original VSFilter, render in YUV directly.

My aim is to increase the precision of both the RGB to YUV conversion (if it 
applies, but I assume this is already implemented) for YUV colourspaces that 
support more than 8 bit of information and to increase the RGB rendering 
bitdepth for animated transform so the colours are defined more precisely 
before conversion to YUV. This obviously applies to alpha-blending onto a YUV 
video.
Also, I aim to increase the RGB bitdepth for these animated transforms when 
outputting via the interface discussed in Issue 91 (earlier Issue 40). 
Currently, it seems that the interface is only able to receive 8 bit RGB data, 
but I think a flag for each frame that uses a higher-bitdepth subtitle line 
might make it possible to do this. Personally, I think that we should for those 
frames match the RGB bitdepth to madVR's internal processing bitdepth, which is 
16 bit. This might be especially important for animated (colour) transforms 
occurring in legacy (BT.601 subtitles on BT.709 video) VSFilter scripts that 
madVR needs to correct, since here, some actual processing of the subtitle line 
takes place.
For these reasons, I ask that xy-VSFilter's internal precision be increased to 
16 bit (or greater).

Original comment by TheDarkS...@gmail.com on 11 May 2012 at 9:25