Esxi running macos For selur

[Selur]

No problem, happy that someone is actually using it.

btw. I just checked and the brew installation finished (so no need to setup yet another VM )

Cu Selur

[Selur]

Okay, good news on the rav1e front brew installs a statically build rav1e version which can be simply shipped with Hybrid.
No further adjustments needed.
Nice.

Cu Selur

[Adamcarter]

I’m glad things are coming together. 

I have never used brew. But remember encountering it when researching waifu.

Seriously selur, you have nomidea how happy i am about waifu.

It’s probably all i am going to run for the next 3 months.

[Selur]

Hopefully you can at least use Waifu2x nvk which is a lot faster than the normal Waifu2x.

Cu Selur

Ps.: got oggenc working it's a bit of a lengthy process to patch the binary it's references and the references of the references, but it seems to work.

[Selur]

Okay, it wasn't brews fault that the installation stalled that long, on the other VM XCode 12 and command line tools now get installed too and it also takes ages without any progress indication.
-> it's MacOSs fault

Seems like the download takes ages,..
-> so no new build today, since I can't build anything while Xcode is udating :/

Cu Selur

Ps.: looking tomorrow into using brew to build mplayer and hopefully mencoder which will probably a nightmare to patch all the dependencies, in case it includes the dependencies Hybrid usually uses,... if not we are probably stuck with old mplayer for quite some time.

PPs.: okay, brew mplayer/mencoder are useless they are only basic builds with no dependencies, so no Xvid encoding, no libbluray, no libass, etc.

[Adamcarter]

Ugh macos is always a headache. Thanks for being a trooper selur. No worries, nothing on mac is urgent, rather you code when you are in a happy place. 

Just running some tests on waifu now. I promise no requests, just want to make sure i am activating the correct settings.

Since scale is defaulted to 1 ‘no scaling’ (i wasn’t planning on doing upscaling) According to the github, the no scaling option doesnt support upconv_7 modes, states cunet is slow but better quality, which i want anyway. 

So i should be using cunet correct? 

Do i need to change the color space to rgb prior or is it handled in the background when i activate the script. 

And does the vsviewer show differences between the different denoising offered by waifu low-highest?
It’s ok if it doesn’t i was looking and couldn’t see a noticeable change, i did get the spinning ball when changing settings so i assume it was working, could be my eyes and i’m just not sure i noticed much change. 

Then again i am doing it thru teamviewer.

[shijan]

Seems short answer for YUV gamma color shift: gamma-correction should be applied to RGB instead of YUV. Gamma correction is really an RGB concept, and is only approximated here in YUV. https://forum.doom9.org/showthread.php?p...ost1923643

[Selur]

So i should be using cunet correct?

yes

Do i need to change the color space to rgb prior or is it handled in the background when i activate the script.

You should never have to mess around with color spaces. Hybrid should do color space conversions if they are needed, if not it's a bug.

And does the vsviewer show differences between the different denoising offered by waifu low-highest?

vsViewer does show the output of the generated script (see: Vapoursynth Script View), and whether you see differences between settings strongly depends on the input and your settings.

small tip: to better spot differences:

• enable 'Filter view'
  
• enable 'Filtering->Vapoursynth->Misc->Preview Settings->SpliView
  
• set 'Filtering->Vapoursynth->Misc->Preview Settings->FilterView Placement' to 'interleave'
  

this way you should see alternating the frames of input and filtered.
Also make sure that 'Crop/Resize->Base->Resize' is enabled otherwise Waifu won't be used.

As a side note: just using Waifu for denoising seems like a waste, you might want to also compare it to normal denoising filters before actually using Waifu.

Cu Selur

[Selur]

Seems short answer for YUV gamma color shift: gamma-correction should be applied to RGB instead of YUV. Gamma correction is really an RGB concept, and is only approximated here in YUV.

Shame that they did not care enough to write that in the Vapoursynth documentation,...

No sure whether I should:
a. automatically convert to RGB when gamma is enabled and planes is not set to 'luma only'.
b. automatically restrict planes to luma only when gamma correction is used
c. add a dropdown behind the Gamma that is active when Gamma is not 1 and that offers:

• restrict to 'luma only' (this would restrict planes to 'luma only' when gamma is not 1)
  
• force RGB conversion (this would make sure when gamma is not 1 the input is RGB)
  
• apply always (would to nothing and work as it does atm.)
  

c. is probably the most 'clean' option, but more work to implement.
-> I'll think about it and may be write some code tomorrow.

Cu Selur

[shijan]

From docs http://www.vapoursynth.com/doc/avisynthcomp.html logic sort of strange. Seems it can adjust global gamma in RGB, but can adjust luma/chroma gamma only in YUV.
planes=1/2 in RGB will only adjust Green and Blue channel .

planes=0 Extracts the first plane. Y for YUV, R for RGB
planes=1/2 = U/V G/B

---

To be honest i can't see any practical usage of Luma chroma gamma.
In most cases people want just adjust global RGB gamma.
In some cases people want adjust per channel RGB gamma.
In some very rare cases may adjust Luma only gamma.

But adjust gamma in chroma - i guess it is impossible at all. Chroma is pure color without tonal curve. Gamma is tonal curve without color. So adjusting gamma in Chroma only (U/V) is just impossible option.

Maybe just use global RGB gamma + RGB per channel gamma + Luma only gamma option?