Selur's Little Message Board

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

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]

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

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]

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

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]

(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):

Code:
# 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")

# Output

As 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.

Code:
# 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")

# Output

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:

Code:
# 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()

I see no artifacts. (Since this should not be a Mac only issue, I took my Windows machine trying to reproduce the problem.)

-> Without a sample that allows me (and others) to reproduce the issue I can't to anything about it.

Cu Selur

To see artifact you need add some LUT in TimeCube + apply some gamma correction in Levels.

Code:
clip = core.std.Levels(clip=clip, min_in=64, max_in=940, min_out=64, max_out=940), gamma=0.50

If 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]

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]

planes: all Gamma adjusted in RGB. This is how any normal gamma adjustment usually look:
[Image: 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]

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

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...1&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

shijan

Selur

shijan

Selur

shijan

shijan

Selur

shijan

Selur

shijan