Conversion of 10/12/14 bit types. Info() new params.#101
Conversion of 10/12/14 bit types. Info() new params.#101qyot27 merged 709 commits intoAviSynth:MTfrom
Conversation
|
Info() was modified. Added font (default Courier New), size (default 18), text_color and halo_color parameters, similar to (but less than) e.g. in ShowFrameNumber. |
|
New functions: ConvertToRGB48, ConvertToRGB64 (similar to 24/32), ConvertToPlanarRGB |
|
Test cases #YUV 8 bit -> Packed RGB OK (still works as in original AVS) #YUV 16 bit -> Packed RGB OK #rgb48->64, 64->48: OK #rgb64 -> Planar RGBAP16 #rgb48 -> Planar RGBP16 #rgb32 -> Planar RGBAP #rgb24 -> Planar RGBP #YUV 16 bit -> Planar RGBP #YUV 8 bit -> Planar RGBP #YUV float bit -> Planar RGBPS |
|
New function name is ConvertToPlanarRGBA() ConvertToPlanarRGB/ConvertToPlanarRGBA usage and test cases: lsmashvideosource("test.mp4", format="YUV420P8") #PlanarRGBA8 -> RGB24 #PlanarRGB8 -> RGB24 #PlanarRGBA16 -> RGB48 #PlanarRGB16 -> RGB48 #PlanarRGBA8 -> RGB32 #PlanarRGB8 -> RGB32 #PlanarRGB16 -> RGB48 #PlanarRGBA16 -> RGB48 #PlanarRGB16 -> RGB64 #PlanarRGBA16 -> RGB64 #YV12 -> YUV420P10 (full scale) -> Planar RGBAP10 -> RGBAP16 (full scale) -> RGB64 |
|
Just to confirm something: should the planar RGB formats return the proper colors at this point, or is there more work for that to occur inside AviSynth+, even if you can deconstruct the planes and put them into packed and have a correct image? I ask, because planar RGB(A) is currently returning greyscale/monochrome images in FFmpeg, and I'm trying to determine if there needs to be something special done on FFmpeg's side to handle it or if the issue is actually just on our side. Like I mentioned, throwing it through PlaneToY/Merge(A)RGB like the testing examples results in the right colors. |
|
I think colors are OK. Either converting back to packed RGB with GetPlane or with the ConvertToRGB24/32/48/64 it gives correct results. |
|
resize_h_c_planar is still in C (todo). Why float? Unsigned_16 handling has overhead and is properly supported from sse 4.1/avx. Tested against the float version and using the float path was indeed faster, even I did not use int64 for temporary result accumulator (int64 because I have a fear that sum of (uint16_t multiplied by 14-bit-scaled-pixel_coefficients) may overflow from signed int when filter_size is bigger. Although my limited tests did not show any visible corruption for the integer path, I went on with floats because of the minor speed difference and the reuseablity with float pixel type. |
|
Conversions from the new RGB types to YUV(A) targets. (todo left: ConvertToY) Note: Slow C code of course :( #8 bit PlanarRGB->YUV420 (YV12) a.ConvertTo8bit() |
|
I was digging a little deeper, and I think the reason FFmpeg is only showing greyscale images for Planar RGB is that the API functions it uses in the blitter (avs_get_read_ptr_p, avs_get_pitch_p, avs_get_row_size_p, avs_get_height_p) still only use the PLANAR_* constants for YUV, not RGB. get_pitch_p: references PLANAR_U, V Using
But
I'm sure not all of the places PLANAR_Y is used signal places that need to be fixed for Planar RGB, but a couple of those places where it's missing do look like they'd be vital to making sure the video stream displays correctly. |
|
If you see greyscale on rgb then
On the other hand VideoInfo struct in the c api did not have planar_a offset and pitch handling. |
|
With the changes in this pull request, and making Planar RGB match the RGB24/32/48/64 case completely (not just pitch, but the BlankClip has some issues with 10~14 depths, it seems.
outputs yellow, but
outputs blue. Also, under Wine, Info() is cropping the text if invoked without arguments, but Info(font="Courier New") doesn't crop the text. The strange thing is that the displayed text isn't in Courier New either time - if anything, it's in Arial or maybe Sans. There's no visible change between the two results except that forcing a font name - and nothing else - makes Info not crop the text. Even if it doesn't honor the font override (I'm simply assuming Courier New isn't installed and that's why it's not used, but it doesn't explain the different behavior when a font is forced vs. left at default). I haven't yet tested whether the changes to AVS_VideoFrame make a difference. That may take a day or two. |
|
When you specify the font (even the default one Courier New) for Info(), it calculates the exact text area, so seeing no cropping is a good news. It renders the whole text as-is for calculation, then sets the rect area by these dimensions and then really renders the text. Because of the double text render (test + real) it is somewhat slower. For speed reasons, when you do not specify font, we assume a fixed font (Courier New is fixed), and the dimensions are calculated in a faster way: calculate horizontal dimension of (max_line_length pieces of spaces), and also vertical dimensions of n lines of single spaces (Space LF Space LF ....) It seems that when you don't have Courier New on your system, the dimensions of the space character are much smaller than of a fixed font space. E.g. Arial or other non-fixed-type space. So the calculation returns a smaller rect area and cropping occurs. Old avisynth routine used hardcoded constants that was unaware of the real size of the text returned by Info(), that was the reason of introducing the calculations above. I think once you have Courier New on your system the cropping won't occur any more. |
|
As for the other issue of 10-12-14 bits: All internal filters assume such bit-depth formats having pixels in 0-65535 range. Range truncation occurs only when calling ConvertTo16bit(10) (12) (14). When you want to have filters work on 10-12-14 bits, use ConvertTo16bit(... truerange=false). The pixel_format will be changed, but the range will stay at 0-65535. It would be a lot of work to treat 10-12-14 bit formats with their real range in all internal filters. Btw, I agree that once we have these formats, limited true range should be the default for either internal or external filter use. Until the development is reaching this point, read source in 10-12-14 bits, convert it with truerange=false for 16 bits, filter, then if the output requires, convert it back with e.g. ConvertTo16bit(10) (note that truerange=true by default to have a 0-1023 range) |
|
Both 16 bit and float resizers are using float arithmetic and coefficients internally. |
|
ColorYUV uses 8-10-12-14-16 bit lut. |
|
Additional infos for ColorYUV
|
|
Conditinal runtime functions got 16 bit/float support for YUV, 16 bit RGB64 support. New functions
16 bit clips result in values in the same 0.0-65535.0 float range for Average and Difference functions, and in 0-65535 range for the min-max-median functions For float color spaces the Min, Max, MinMaxDifference and Median functions return values scaled to 16 bits (pixel counts are populated as 16 bit samples internally). Other functions (Average and Difference functions keep the the normal 0-1.0 float range) |
|
Test scripts |
|
Test scripts for Levels |
|
RGBAdjust: |
|
Invert test scripts |
|
Mask test scripts |
|
GreyScale for new formats. SSE4.1 for RGB64. |
|
It would appear that PlanarRGBA->YUV444 is the only path where the alpha plane is actually copied to the output, resulting in YUVA444 as expected. Going to YUV420 or YUV422 drops the alpha plane. Some things that would/might be useful:
|
|
Layer() for RGB64. New extension: |
|
The pixel_format vs. pixel_format name lookup was implemented multiple times. Pixel type name from pixel type: that is straightforward 1-1. GetPixelTypeFromName now is also used in Overlay (work in progress) |
|
Test script for Overlay "add" function (10-16 bit for any type input). |
|
Tweak: luma + chroma LUT for 10 bits and luma LUT for 10-16 bits |
|
ColorKeyMask color and tolerance parameters are the same as for 8 bit RGB32, internally they are automatically scaled to the current bit-depth |
|
ConvertBits() for all-in-one bit-depth conversion: c[bits]i[truerange]b[dither]i[scale]f Video format override between 10-16 bit formats (no content change) dither is still todo |
Refinements to GCC plugin stuff
|
Given the recent events involved with the repository, I'd say we should go ahead and merge this. If there are no objections, I'll do so tomorrow or Saturday. |
|
Agreed, thanks, my days are a bit busy now. |
When a color space with bit-depth 10/12/14 is involved, conversion assumes the real 10-12-14 range, unless truerange=false is specified.
When truerange==false, the internal range is expanded to 16 bits, only the pixel_format hints to the limited range.
YUV(A) conversions are using bit-shifts. For planar RGB, full range is used (0-1023/4095/16383/65535). Planar RGB is always using 65535 when truerange==false is specified.