Esxi running macos For selur

[shijan]

Yep, probably "Transfer" 'From' or 'To'  Rec 2020 make sense. For example Rec2020 with Rec709 gamma is a proper specification for non HDR wide gamut video. VLC player can read and color manage files like these.

[Selur]

VLC seems to be always broken in one way or the other when I use it, even MPV usually performs better.

Cu Selur

[shijan]

By the way, maybe instead of separate Transfer option it is simpler just add presets for HDR and SDR? For example this is how similar color/gamma transform options look in other Apple apps.
From other point of view, more flexible and less restricted Color Space Transform plug-in may be useful in some situations as well.
Naming also important. For example Rec. 709 (with space) but BT.709 without space https://en.wikipedia.org/wiki/Rec._709 (always was confused by multiple naming of same thing from those industry recommendations, but probably Rec. 709 is the final and most recognized naming for today)

[Selur]

I took the transfer characteristics names:

//values << QString("reserved"); // 0
  values << QString("709"); // 1
  values << QString("unspec"); // 2
  //values << QString("reserved"); //3
  values << QString("470m");
  values << QString("470bg");
  values << QString("601");
  values << QString("240m");
  values << QString("linear");
  values << QString("log100");
  values << QString("log316");
  values << QString("xvycc");
  values << QString("srgb");
  values << QString("2020_10");
  values << QString("2020_12");
  values << QString("st2084");
  values << QString("std-b67");

from http://www.vapoursynth.com/doc/functions/resize.html
-> if you give me a list of more common names I can adjust the names.

From other point of view, more flexible and less restricted Color Space Transform plug-in may be useful in some situations as well.

If someone writes one for Vapoursynth I can add support for it, atm. I use the basis resize functionality to implement color matrix changes, so only color spaces supported by Vapoursynths resize are available.

Cu Selur

[shijan]

Ok, got it. Seems not so simple task. Probably Transfer characteristics and other renaming to more human friendly language needs some deeper work and research. I can do it based on Davinci Resolve and some other apps color spaces naming and based of x265 tads wikli https://x265.readthedocs.io/en/default/c...-colorprim. 
By the way, there are also same VUI tags in many other different places: In ProRes, in x264 and in x265 settings. So if rename things in future - rename them all together in all places.
Those color space transfer and tags in video containers are slightly different from input ColorMatrix. They don't change source pixels data, but just inform video player how to transform video gamma and color space during playback (Sort of ICC profile for video).

[Selur]

Problem is not all encoders support the same things so renaming them all at the same time will probably not happen.

Those color space transfer and tags in video containers are slightly different from input ColorMatrix.

Thats because transfer characteristics and color matrixes are totally different things that are named differently in the standards to avoid confusion or the thinking that some thing need to be combined/associated if they don't have to.
-> trying to get the same names for transfer characteristics, profiles, colro matrices, etc. is not something that should be done.

Cu Selur

[shijan]

I didn't mean to use "same names for transfer characteristics, profiles, color matrices," I mean to use more defined names instead of pure tags.

Like "bt2020-12" renamed to "Gamma Rec. 2020 (12 bit)"

But there is no any common defined specification how to rename those tags in human friendly way. Each app use it's own renaming system. Even media inspectors apps rename those tags to normal text.


But anyway it is not critical problem at all. Just a discussion. Native VUI tag names have it's own charm

[shijan]

I place request for timecube and HaldCLUT here https://github.com/sekrit-twc/timecube/issues/3

Do you think pixelated effect could due some mistake in plug-in or it is something related to Hybrid? Should i notice developer?

[Selur]

Since the pixelation doesn't happen to me on Windows, but it does happen even when using the software renderer in the MacOS VM and the script itself

# Imports
import vapoursynth as vs
core = vs.get_core()
# loading source: /Users/selur/Desktop/test.avi
# color sampling YUV420P8@8, matrix:470bg, scantyp: progressive
# luminance scale TV
# resolution: 640x352
# frame rate: 25 fps
# input color space: YUV420P8, bit depth: 8, resolution: 640x352, fps: 25
# Loading source using FFMS2
clip = core.ffms2.Source(source="/Users/selur/Desktop/test.avi",cachefile="/Users/selur/temp/avi_c6b2c493052375dcc56052d30e195c86_853323747.ffindex",format=vs.YUV420P8,alpha=False)
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg",range_s="limited")
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip, fpsnum=25, fpsden=1)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# adjusting color space from YUV420P8 to RGB24 for vscube
clip = core.resize.Bicubic(clip=clip, format=vs.RGB24, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="/Users/selur/workspace/Hybrid/Hybrid.app/Contents/MacOS/TimeCubeFiles/BT709_to_PQ_800.cube")
# adjusting output color from: RGB24 to YUV420P8 for x264Model (i420)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, matrix_s="470bg", range_s="limited")
# Output

does look fine to me, my guess is that it either:
a. a problem with the compilation
b. a opencl / opengl problem on MacOS
I do not think that this is anything I can fix in Hybrid.
So either sekrit or it's a problem with the library compilation.

Cu Selur

[shijan]

amazing!!!
Guess more correct and common is name "View" but not "Views"