+- Selur's Little Message Board (https://forum.selur.net)
+-- Forum: Talk, Talk, Talk (https://forum.selur.net/forum-5.html)
+--- Forum: Small Talk (https://forum.selur.net/forum-7.html)
+--- Thread: Esxi running macos For selur (/thread-1495.html)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
RE: Esxi running macos For selur - shijan - 16.09.2020
Just an idea. Seems there is some wasted empty space at the bottom that can be adjusted to extend usable window area for filters.
Seems that empty space appears due some new resize logic experiments. Window resize now behaves strange. Instead of resizing filters area, it resizes both parts of window.
![[Image: RkGQuco.jpg]](https://i.imgur.com/RkGQuco.jpg)
RE: Esxi running macos For selur - Selur - 16.09.2020
The resizing effect was intentional. (I'm testing a few things)
The fact that window resizing is possible at all is not.
Must be something they changed in MacOS, normally resizing is disabled in Hybrid.
Cu Selur
RE: Esxi running macos For selur - shijan - 16.09.2020
Haha, so it was a bug. I always like macOS version for option to resize window. Sometimes it helps a lot to navigate multiple filters with no vertical scrolling. When i switch tabs in upper row, Hybrid back to it's default size. So it looked like very logical behavior. It worked like this in 2018 version as well.
When i try to install Windows version on virtual machine some time ago, i was confused why Hybrid window is so small and why i can't resize it.
Sort of this:
![[Image: VYqwJX8.jpg]](https://i.imgur.com/VYqwJX8.jpg)
RE: Esxi running macos For selur - Selur - 16.09.2020
Uploaded a new version.
I removed the resize and the disableIcons option, did some small changes.
Moved log in Base-tab over 'Add to Queue'&Co-buttons. (not sure if I like this more or not)
Going to bed.
Cu Selur
RE: Esxi running macos For selur - shijan - 17.09.2020
Quote:Moved log in Base-tab over 'Add to Queue'&Co-buttons. (not sure if I like this more or not)I like it. Seems that group of render related buttons now better separated from others. And similar bottom progress bar already used in "Jobs" tab.
Quote:I removed the resize and the disableIcons option.This is really strange. Why restrict essential usability like this? What is wrong if user can see larger sized filters window? What if someone use dual displays and prefer to see full screen Hybrid window on one display and vsViewer on other display?
Also yet these changes only generate UI bugs:
Horizontal scroll now visible in: Color, DeNoise, DeGrain, Sharpen tabs.
At the start Hybrid now jumps to upper top corner of the screen and don't remember its position on screen.
If i turn off tooltips sidebar, i still can resize window horizontally, but it feels laggy to resize.
I'll personally stay with Hybrid_wip_2020_09_15 yet and can't see any point in future bug reports participation without those options. Filters window resize and disableIcons are just too critical options for my essential near everyday work.
Seems i understand the source of horizontal scroll problem in some tabs. UI see all filters in the tab. Even if some filter with extra wide controls is currently not selected, UI see it and and adds horizontal scroll.
Probably simple way to fix it - just use wider default UI size (or allow Hybrid to remember UI size adjusted by user as any normal app can do).
Complicated way to fix it - rearrange control elements in every "too wide" filter.
![[Image: nAH5jwQ.jpg]](https://i.imgur.com/nAH5jwQ.jpg)
![[Image: Infwtk2.jpg]](https://i.imgur.com/Infwtk2.jpg)
RE: Esxi running macos For selur - shijan - 17.09.2020
(14.09.2020, 22:13)Selur Wrote:Quote:Levels Gamma + TimeCube together produce some strange results:Do you see a mistake in the script?
If not, than it's not a bug in Hybrid.
Also without details that actually allow to reproduce the issue I won't even try to reproduce this.
Like last time when you didn't mention at all that you use a high bit depth source and I spend an evening searching for a bug that I couldn't find,...
From developer's explanation TimeCube operates internally in 32 bit float RGB.
Currently Hybrid script use bit depth of input video as input for TimeCube and next just apply Levels (I used 10bit source video in this example):
# adjusting color space from YUV422P10 to RGB30 for vscube
clip = core.resize.Bicubic(clip=clip, format=vs.RGB30, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="/Applications/Hybrid.app/Contents/MacOS/TimeCubeFiles/identity.cube")
# Color Adjustment
clip = core.fmtc.resample(clip=clip, kernel="spline16", w=1440, h=1178, interlaced=False, interlacedd=False)
# adjusting output color from: RGB30 to YUV422P10 for ProResModel (i422)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV422P10, matrix_s="470bg", range_s="limited")
# OutputAs i noticed earlier it produce some strange conflict in colors.
Here is solution:
I was thinking maybe TimeCube outputs 32bit but Levels and other similar filters expect same bit depth as source video? So i try to customize script, and add additional transformation to YUV422P10 before Levels. And it WORKS! No more conflict between Levels and TimeCube.
# adjusting color space from YUV422P10 to RGB30 for vscube
clip = core.resize.Bicubic(clip=clip, format=vs.RGB30, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="/Applications/Hybrid.app/Contents/MacOS/TimeCubeFiles/identity.cube")
# color adjustment for Levels
clip = core.resize.Bicubic(clip=clip, format=vs.YUV422P10, matrix_s="470bg", range_s="limited")
# Color Adjustment
clip = core.std.Levels(clip=clip, min_in=64, max_in=940, min_out=64, max_out=940, gamma=0.50, planes=[0])
clip = core.fmtc.resample(clip=clip, kernel="spline16", w=1440, h=1178, interlaced=False, interlacedd=False)
# adjusting output color from: RGB30 to YUV422P10 for ProResModel (i422)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV422P10, matrix_s="470bg", range_s="limited")
# OutputRE: Esxi running macos For selur - Selur - 17.09.2020
Your finding suggests that either:
a. Levels filter does not properly support RGB30, or
b. TimeCube does not output the color format it is fed or somehow outputs a broken version of it
and that adding some additional color space conversion does fix the problem.
So assuming I can reproduce the problem and identify what is causing the issue.
For a. could contact the Vapoursynth developers and they could fix the issue.
For b. the author of TimeCube could fix the issue (or I could add Warning-Popup to Hybrid and add an additional color conversion)
Problem is:
I can not reproduce the problem where I see artifacts when I feed RGB30 content to TimeCube and apply Levels afterwards.
Using:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/ColorFilter/TimeCube/vscube.dll")
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll")
# loading source: F:\TestClips&Co\files\10bit Test.mkv
# color sampling YUV420P10@10, matrix:470bg, scantyp: progressive
# luminance scale TV
# resolution: 640x352
# frame rate: 25 fps
# input color space: YUV420P10, bit depth: 10, resolution: 640x352, fps: 25
# Loading F:\TestClips&Co\files\10bit Test.mkv using LWLibavSource
clip = core.lsmas.LWLibavSource(source="F:/TestClips&Co/files/10bit Test.mkv", format="YUV420P10", cache=0)
# 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 YUV420P10 to RGB30 for vscube
clip = core.resize.Bicubic(clip=clip, format=vs.RGB30, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="C:/Users/Selur/Desktop/identity.cube")
# Color Adjustment
clip = core.std.Levels(clip=clip, min_in=64, max_in=940, min_out=64, max_out=940)
# adjusting output color from: RGB30 to YUV422P10 for ProResModel (i422)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV422P10, matrix_s="470bg", range_s="limited")
# Output
clip.set_output()-> Without a sample that allows me (and others) to reproduce the issue I can't to anything about it.
Cu Selur
RE: Esxi running macos For selur - shijan - 17.09.2020
To see artifact you need add some LUT in TimeCube + apply some gamma correction in Levels.
clip = core.std.Levels(clip=clip, min_in=64, max_in=940, min_out=64, max_out=940), gamma=0.50If other filters with 32 bit RGB internal processing don't require additional RGB->YUV transformation after them, it is probably a bug in TimeCube and i can contact TimeCube developer.
From other point of view, it sounds logical to output maximum possible bit depth and unchanged color to provide more data to other filters. So TimeCube may be just designed like this.
10 bit source -> 32 bit TimeCube -> 32/16 bit color correction -> 32/16 bit noise Reduction -> 32 bit resize -> export to 12 or 10 bit video file.
At least apps like Davinci Resolve and similar works like this. They upscale any source to 32 bit RGB internally for color correction and other filters processing.
P.S. I read some tips http://www.vapoursynth.com/doc/functions/levels.html http://www.vapoursynth.com/doc/avisynthcomp.html and played with Levels green/purple gamma shift bug, and seems i also believe that it is a bug in Vapoursynth.
Gamma correction works normally if source transformed to RGB. But in YUV it produce green/purple gamma shift.
And just to illustrate my explanation that luma only gamma is not the same as normal gamma:
planes: all Gamma adjusted in YUV. Green/Purle color shift problem (probably bug in Vapoursynth):
![[Image: 19167W1.jpg]](https://i.imgur.com/19167W1.jpg)
planes: luma Gamma adjusted in YUV. No color shift problem, but "desaturation" effect that is essential for this sort of luma only adjustment.
![[Image: pU5xRll.jpg]](https://i.imgur.com/pU5xRll.jpg)
planes: all Gamma adjusted in RGB. This is how any normal gamma adjustment usually look:
![[Image: tx0WgKI.jpg]](https://i.imgur.com/tx0WgKI.jpg)
As a reference here is screengrab with gamma adjusted PhotoLine graphic editor. Some difference may be due video player screengrabs color management and range transformations, but overall look is near the same. It is dark but not desaturated:
![[Image: CdztCXQ.jpg]](https://i.imgur.com/CdztCXQ.jpg)
RE: Esxi running macos For selur - Selur - 17.09.2020
Since you didn't share a link to a file that does allow me to reproduce the issue, best report this to the Vapoursynth developers over at doom9s.
Cu Selur
RE: Esxi running macos For selur - shijan - 17.09.2020
Green/purple gamma shift may be reproduced with any file and any bit depth. I already reported here https://forum.doom9.org/showthread.php?t=165771&page=205
------
TimeCube + Levels gamma conflict is very easy to see if you apply black&white LUT. See attachment. It works the same with any file and any bit depth. This is how reproduced poblem should look:
TimeCube LUT + Levels gamma 0.5 (planes: luma) = light color cast
TimeCube LUT + Levels gamma 0.5 (planes: all) = no color cast. Pure desaturated image. (this is because TimeCube outputs RGB)
Levels gamma 0.5 (planes: luma) = no color cast. Pure desaturated image.
Levels gamma 0.5 (planes: all) = strong green color cast