Dogway's Filters Packs

[Dogway]

LeXXuz, I cannot reproduce your issue. I used your settings over a 2.40 ratio 1080p source at 16-bit.

What did you change between this (https://abload.de/img/2022-07-29452j8t.png)and this (https://abload.de/img/2022-07-2958qk14.png)? Result looks fine but no settings changed?

The legend is when you define show="speed" in string format so you can have some hint where to tweak for optimization.

[LeXXuz]

What did you change between this (https://abload.de/img/2022-07-29452j8t.png)and this (https://abload.de/img/2022-07-2958qk14.png)? Result looks fine but no settings changed?


Weird. I changed nothing, just stepped a frame forward in MeGUIs preview window and took a new screenshot. Some frames look fine, others have these strange colour distortions.

I did a few encodes with DGDenoise() just alone to see if these errors occur, but no. Have latest nVidia Studio drivers installed for RTX 2060. I will check this very same script on another machine with a RTX 3060TI once that's free as it's currently occupied by running a longer encoding job.

EDIT: That is actually not true. It does also happen with DGDenoise() alone.

[Dogway]

Just upload a small sample and your script so I can test here.

Is the source interlaced? (a possible point of failure)

[LeXXuz]

Is the source interlaced? (a possible point of failure)

No it's 1920x800 @23p.

[madey83]

Dogway I noticed some faint distortions in my encodes, barely noticeable.
So I played around with the preview mode a little and saw a lot of erroneous frames of the prefiltered clip. See pics below:

https://abload.de/thumb/2022-07-291tjjv3.png (https://abload.de/image.php?img=2022-07-291tjjv3.png)https://abload.de/thumb/2022-07-292b4kjm.png (https://abload.de/image.php?img=2022-07-292b4kjm.png)https://abload.de/thumb/2022-07-2931lknh.png (https://abload.de/image.php?img=2022-07-2931lknh.png)https://abload.de/thumb/2022-07-29452j8t.png (https://abload.de/image.php?img=2022-07-29452j8t.png)https://abload.de/thumb/2022-07-2958qk14.png (https://abload.de/image.php?img=2022-07-2958qk14.png)https://abload.de/thumb/2022-07-290uk5b.png (https://abload.de/image.php?img=2022-07-290uk5b.png)

EDIT: I turned off DGDenoise and the errors are gone. Tried with no prefilter (-1) and BM3DCUDA (6) with no errors.

Btw. about "speed, memory and quality" shown on the right with different colours. Are they displayed anywhere? All I see is the gamma curve in the preview.

hi LeXXuz,

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?

[LeXXuz]

hi LeXXuz,

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?

No. That is just the Avisynth preview window of MeGUI:
https://forum.doom9.org/showthread.php?t=112496

[StainlessS]

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?
I'm not sure what you are after, but maybe WaveForm_FilmStrip() will fit the bill.

https://i.postimg.cc/nV44Lx6B/Waveform-Filmstrip-00.jpg (https://postimg.cc/4n378D4x)

Here in WaveForm thread:- https://forum.doom9.org/showthread.php?p=1965005#post1965005

Here client script with SHOWAUDIO=False [where it dont need Waveform plugin]


# Import(".\Waveform_FilmStrip.avsi")
#AviSource("D:\G.avi")
Colorbars.Trim(0,-100)

WINDOW = 3 # Frames Wide = 2 * WINDOW + 1
HEIGHT = 0.33 # Audio graphs height, 0.333 = 1/3 of result filmstrip image height.
UNDER = false # True, then audio graphs stacked under video, else overlay over video.
ZOOM = 1.0 # Amplify audio signal for viewing (1.0=No Amp).
SUBSIZE = 0.5 # Suggest 0.0(off) to about 0.5. (0.0 <= SubSize <= 1.0) : 0.0 = No Frame Number, 1.0=biggest size for current clip Height (probably too big).
SHOWAUDIO = False # Default True. If False, Switches OFF WaveForm Display, Shows FilmStrip Only.
W = 264 # Default -1, (or 0 or +ve). -1 = Normal Downscale behaviour, filmstrip width ~= input clip width.
#H = Undefined # Undefined, Let W govern height of thumbnail images (or just dont use h=H in function call, same as h=Undefined).

###### Can Remove this lot ######
TONE = False # Replace Colorbars tone with selected TONETYPE tone
TONETYPE ="NOISE" # Pick from:- "Silence", "Sine", "Noise", "Square", "Triangle" or "Sawtooth"
TONECHANS = 5 # Tone Channels Count (test channels display)
#
(TONE) ? AudioDub(Tone(Length=FrameCount/FrameRate,Type=TONETYPE,Channels=TONECHANS)) : Last
###### End Of Can Remove ######
WaveForm_FilmStrip(window=WINDOW,Height=HEIGHT,under=UNDER,zoom=ZOOM,subSize=SUBSIZE,ShowAudio=SHOWAUDIO,w=W) #,h=H)
Return Last


EDIT: The Waveform_FilmStrip() script at linked post is the most recent version.

EDIT: If Waveform_FilmStrip.avsi aint in plugins, then need to import it.

EDIT: And here with SHOWAUDIO=TRUE [but animated gif(via VDub2 export) dont have audio, so silent]
https://i.postimg.cc/6p1FqnD7/Waveform-Filmstrip.gif (https://postimg.cc/xXM6FJjY)

EDIT: If required, you could eg Interleave(Clip_A, Clip_B) and use result with WaveForm_FilmStrip, even frames would be Clip_A, odd Clip_B,
or just use eg StackHorizontal(Clip_A,Clip_B) to view side by side.

[ENunn]

Using SMDegrain and I'm having issues with random corruption artifacts. It happens randomly and I can't seem to find a fix.

https://i.imgur.com/0fMctji.png
SMDegrain(prefilter=5, str=0.8, refinemotion=true)


Any fix? Running AVS+ 2.7.2 and using the latest SMDegrain script. This doesn't occur in the source, and I have been using TempDegrain2 in the meantime with no issue, but it's painfully slow.

[Dogway]

AVS+ 3.7.2?
Update a small sample and full script since I'm not getting that issue.
Try with prefilter=-1 to see if it's ex_KNLMeansCL() related. Check dependencies as well.

[ENunn]

AVS+ 3.7.2?
Yeah, typo :P

Update a small sample and full script since I'm not getting that issue.
Here's the sample. (https://mega.nz/file/n8d12YZR#mWX-AXbxCvVbY5tM0V0oHBqXhsDokvdXBLaw1AF6ayE)


AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
#ChromaShiftSP(X=-.85, Y=-.25)
ConvertToYv16(matrix="rec601",interlaced=false)
MergeChroma(aWarpSharp2(depth=20,threads=4))MergeChroma(aWarpSharp2(depth=10,threads=4))
santiag(strv=0, nns=4, nsize=5, threads=4)
#converttoyuy2(matrix="rec601", interlaced=false)
SMDegrain(prefilter=-1, str=0.8)


I also tried simply

AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
SMDegrain(prefilter=-1, str=0.8)

The issue was still there, although the result is different. Looks like it depends on both the source and what's behind smdegrain. Might not show up for you at all yet it shows up for me.

I did take out the tweak and convertbits lines, looks like the issue doesn't happen there, but I need those lines.

Try with prefilter=-1 to see if it's ex_KNLMeansCL() related.

Same result.

Check dependencies as well.
Where can I find a list of them?

[Dogway]

I don't have any global HuffYUV decoder installed so I used FFMS2 loader and it didn't show any issue.

I think it must have to do with the source loader, try other one. Also just updated QTGMC+ although I don't think it's related.

For good measure try to trim after deinterlacing.

[Boulder]

You could also try adding RequestLinear(clim=100) right after the source and see if the issue disappears.

[kedautinh12]

Yeah, typo :P


Here's the sample. (https://mega.nz/file/n8d12YZR#mWX-AXbxCvVbY5tM0V0oHBqXhsDokvdXBLaw1AF6ayE)


AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
#ChromaShiftSP(X=-.85, Y=-.25)
ConvertToYv16(matrix="rec601",interlaced=false)
MergeChroma(aWarpSharp2(depth=20,threads=4))MergeChroma(aWarpSharp2(depth=10,threads=4))
santiag(strv=0, nns=4, nsize=5, threads=4)
#converttoyuy2(matrix="rec601", interlaced=false)
SMDegrain(prefilter=-1, str=0.8)


I also tried simply

AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
SMDegrain(prefilter=-1, str=0.8)

The issue was still there, although the result is different. Looks like it depends on both the source and what's behind smdegrain. Might not show up for you at all yet it shows up for me.

I did take out the tweak and convertbits lines, looks like the issue doesn't happen there, but I need those lines.



Same result.


Where can I find a list of them?

Depen here:
https://github.com/Dogway/Avisynth-Scripts/blob/1c94f882e232768d2d7b60fa13b47b94a2af1793/SMDegrain%20v3.5.3d/SMDegrain%20v3.5.3d.avsi#L30

[ENunn]

I don't have any global HuffYUV decoder installed so I used FFMS2 loader and it didn't show any issue.

I think it must have to do with the source loader, try other one. Also just updated QTGMC+ although I don't think it's related.
Loaded it with LWLibavVideoSource, same issue. Updated QTGMC+ and it said something along the lines of "there's no such thing as field" or something like that, so I rolled back.

For good measure try to trim after deinterlacing.
"RequestLinear: internal error (frame not cached)!" It wouldn't be a reliable fix even if it was a solution because scrubbing with QTGMC is painfully slow hence why I trim before deinterlacing.

You could also try adding RequestLinear(clim=100) right after the source and see if the issue disappears.
Didn't fix it.

Depen here:
https://github.com/Dogway/Avisynth-Scripts/blob/1c94f882e232768d2d7b60fa13b47b94a2af1793/SMDegrain%20v3.5.3d/SMDegrain%20v3.5.3d.avsi#L30
Thanks, issue still persists even with everything installed/updated though.

[Dogway]

I borked it (QTGMC), fixed now hopefully (along ResizersPack). In any case previous version (3.85) should be working.

My guess is that something is not up to date...

As per your comments everything runs fine until the SMDegrain call? Are you on x86 or x64?

Another thing, try with str=1 or str=0, str=0.8 invokes ex_retinex() which is good but that might be causing you some issue.

I'm going to update SMDegrain very soon but I don't think anything is related to your issue (mostly fixes for UHD)

[DTL]

"going to update SMDegrain very soon"

There is a faster interpolated overlap modes of MDegrainN - 4x in current release of 2.7.45+ and even faster diagonal overlap 2x hope in next release this week. It allow to run MAnalyse(overlap=0) for faster processing and make interpolating of MVs for 'classic' overlap (4x mode IntOvlp 1 and 2) and close or equal to BlockOverlap old plugin (IntOvlp 3 and 4) - 2x 'diagonal shifted' mode. 4x and 2x are number of blocks to process by blending engine so 2x expected to be about 2x faster. No overlap is 1x blocks number. So there will be very many combinations of speed/quality settings. May be for warp-around scripts it need to be arranged into 'speed_quality' single setting with values like slowest/slow/medium/fast/fastest or 1..10 integer value decoded internally into set of different processing modes.

Also 'diagonal' shifted mode may be further expanded for speed/quality different sets of processing modes like 'diagonal overlap' onCPU MAnalyse and diagonal overlap onHWAcc MAnalyse (it is easy compatible with accelerators ME search). With 'real searched' 2 sets of MVs (not interpolated second set inside MDegrainN). Though simple and fastest 2x diagonal interpolated mode already shows good results for everyday usage. Most of 4x-classic modes are expected to move to 'rarely use placebo'.

[Dogway]

I think I should do a fork of SMDegrain with your plugin so we can debug and get a hang of it. I'll make two versions a stripped down to focus only debugging, and another aligned with master. I'll wait for your release, then I'll try to update the ancient documentation.

[DTL]

I already update most of documentation for changed mvtools filters params at github https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/Documentation/mvtools2.html . Only will add IntOvlp modes 3 and 4 (2x diagonal overlap with SAD re-check and 2x with interpolated SAD) after new fixed release. Currently it working only for inside frame and to use full frame area without distorted edges require addborders and crop of block-size size. Going to fix overlap windows for borders of frame processing soon. The 2x diagonal overlap require full separate set of overlap windows different from classic overlap of mvtools.

In classic mvtools the blocks number of 'dynamic' so 4x is worst case with overlap=blocksize/2 V and H. With large blocksize like 16 or 32 and small overlap size like 2 the number of blocks may be less than 2x even. But large blocks do not track complex motion good and only good for large static of no-detailed areas.

The formula of blocks number in 'classic' mvtools overlap is
nBlkX = (nWidth - nOverlapX)
/ (nBlkSizeX - nOverlapX);
nBlkY = (nHeight - nOverlapY)
/ (nBlkSizeY - nOverlapY);

So total blocks number nBlkX_x_nBlkY greatly depends on overlap length and block size and so overhead of overlap processing and speed degradation.
With small block size like 8 or 4 even small overlap like 2 greatly increases blocksnumber and degrades processing speed.

Update: New version with faster 2x diagonal overlap mode ready for testing - https://forum.doom9.org/showthread.php?p=1972579#post1972579

[hello_hello]

Dogway,
I've just started playing around with some of your functions.... lots of good stuff there.... but I have some questions regarding ConvertFormat's color conversion. Mostly regarding the change in transfer function from rec.709, but also regarding the change in primaries when _Matrix is correct for the target resolution. If _Matrix is correct but the primaries and transfer aren't set, should they be assumed to be correct too?
Also, what's the logic behind automatically changing the primaries from 601-625 to 601-525 (I'm assuming that's what colorspace refers to when show=true)? That also happens when the image is already SD and there's no resizing.

Thanks.

A 720p image without any color correction before resizing.
Spline36Resize(640,360)
https://i.ibb.co/CQGJ0G3/A.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/ns8LFtN/AA.jpg

Matrix only color conversion before downscaling (fmtconv).
Spline36Resize(640,360)
propShow()
https://i.ibb.co/pXnWD7v/B.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/251L6dM/BB.jpg

Matrix and primaries to 601-625 before downscaling.
Spline36Resize(640,360)
propShow()
https://i.ibb.co/ydwnXNZ/C.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/JyFqphT/CC.jpg

Matrix and primaries to 601-525 before downscaling.
Spline36Resize(640,360)
propShow()
https://i.ibb.co/h8k711s/D.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/Ytz6fXb/DD.jpg

[Dogway]

hello_hello, all the settings in ConvertFormat are infered from matrix/primaries (or frameprops as fallback). So if you type "709" it will assume D65, 1886 transfer, etc, unless you explicitly override them. If for example you want to keep 1886 transfer instead of correct (for SD) 170M one, set EOTF="".

There's a point of contemption for 470BG transfer, for RC54 I just changed it from academic 470BG transfer (2.8 gamma) to 170M transfer which is what was used in real world. But I'm open to suggestions.

By the way you can simply do ConvertFormat(640,show=true) to keep ratio.

TransformsPack is a bit of my color lab, I'm trying to do things a bit differently than other solutions out there by not hard-coding values but deriving them as most as possible. Also playing with more advanced concepts as alternative LMS spaces and soon gamut compression. As well as adding different color models while keeping usability intuitive enough.

I'm fixing chromatic adaptation and a small issue in PC levels and releasing v1.0 very soon maybe within this month, so bug reports will be very welcome. I also need to have a look at libplacebo from asd-g to see what can be integrated. From there on until 2.0 I will add the rest of primaries+transfer list, implement color models into ConvertFormat, gamut compression and preset system (in no order).

[hello_hello]

Thanks for the reply.
I'm still not sure I understand the changing of transfer from 1886 to 170m when resizing HD to SD though. I thought 1886 was a display gamma (simulating a CRT) and rec.709 and SD used the same transfer function, but maybe I'm misunderstanding that. 1886 to 170m obviously changes the picture though (and 170m to 1886 when upscaling makes it brighter), and I would've assumed the idea of color conversion when changing resolution would be for the picture to display the same as it did originally.

I used fmtconv to convert the colors, and the transfer choices for SD appear to be "601" or "470BG". I used the former and fmtconv set _transfer=6, which I assume is the same as 170m, but I was curious about the need to change the primaries from "470bg" (5) to "170m" (6) when _transfer=6, assuming they both do use the same transfer function.

This stuff still confuses me at times, so I'm asking out of curiosity, rather than implying it's wrong.

Cheers.

[Dogway]

Yes I checked again H.273 and indeed Transfer ID 1, 6, 14 and 15 all share same transfer (170M) (quote: For
TransferCharacteristics equal to 1, 6, 14 or 15, a has the value 1 + 5.5 * ß = 1.099296826809442... and ß has the value
0.018053968510807....), but this is contradictory because elsewhere (DaVinci, Nuke) Rec709 is associated with pure power gamma of 2.4 or 1886 set to 2.4, check for example here (https://github.com/ampas/aces-dev/blob/eaf92310789f3e45284214c56f806a965c087a08/transforms/ctl/odt/rec709/ODT.Academy.Rec709_100nits_dim.ctl#L115). ACES reference ODT Rec709.

This is typical for delivery, you use 2.40 for consumer media, 2.60 for theaters... Now what is 170M for Rec709 then? In Nuke there's also a Rec709 (~1.95) option, this is acquisition gamma as far as I know and matches roughly 170M. I read a lot about it at the time and there are many places that discusses the topic.

Here is a quote from my notes:
*While Rec. 709 does not specify the display referred gamma, display gamma is discussed in EBU Tech 3320 and specified in ITU-R BT.1886 as a gamma of 2.4. This is a higher gamma than the 1.95 the math shown above would indicate, because the television system has been deliberately designed with an end-to-end system gamma of about 1.2, to provide compensation for the ‘dim surround’ effect. Therefore, the monitor gamma is not the inverse of the camera gamma.

I would've assumed the idea of color conversion when changing resolution would be for the picture to display the same as it did originally.

If you do a color space conversion the colors are going to change no matter what, unless you pass it through a viewing transform ( Display_referred() )

I used fmtconv to convert the colors, and the transfer choices for SD appear to be "601" or "470BG". I used the former and fmtconv set _transfer=6, which I assume is the same as 170m, but I was curious about the need to change the primaries from "470bg" (5) to "170m" (6) when _transfer=6, assuming they both do use the same transfer function.

I don't know about fmtconv but in ConvertFormat() the transfer and illuminant are inferred from matrix/primaries not the other way around. In any case as I commented above, academic 470BG is 2.8 gamma, but as I could read this was never used in practice (just like 470M space), so I changed the infer to point PAL->170M, you can still override the transfer with "470BG".


EDIT: Here is an excerpt of page 6 of REC-BT.601-7 (in force).
In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Rec.ITU-R BT.1886, in the reference viewing environment defined in Rec. ITU-R BT.2035. Although some parameters listed in Recommendation ITU-R BT.2035 are intended for HDTV signal viewing, scaled viewing distances for SDTV signals should be used.

So probably I should switch all SD transfer functions to 1886, and leave 170M when you need to get the linear signal (inverse OETF or EETF).

[hello_hello]

When I said that after a color conversion I'd expect the video to display the same way, I realise the colors have to change, but I was looking at it in terms of a matrix conversion where if you convert from 709 to 601 for downscaling the colors change, but they display the same way (ignoring the difference in primaries).

*While Rec. 709 does not specify the display referred gamma, display gamma is discussed in EBU Tech 3320 and specified in ITU-R BT.1886 as a gamma of 2.4. This is a higher gamma than the 1.95 the math shown above would indicate, because the television system has been deliberately designed with an end-to-end system gamma of about 1.2, to provide compensation for the ‘dim surround’ effect. Therefore, the monitor gamma is not the inverse of the camera gamma.

Is that where the change in brightness/gamma is coming from in ConvertFormat?

I had assumed that to convert rec.709 gamma to SD gamma, which I gather has the same OETF anyway, but if it didn't you'd apply an inverse of the rec.709 OETF, taking you back to linear light, and from there apply the destination gamma curve. The way it seems to me is the BT.1886 EOTF would only be used at the display stage. The example for converting the rec.709 primaries on wikipedia (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics) says BT.1886 shouldn't be involved.

As far as 470BG goes, I'm not worried about being able to use it as a transfer function, but if PAL->170M, does that mean ConvertFormat can't convert the primaries to 470BG/601-625/PAL? Not that I think it matters much, but given the 470BG primaries are closer to the rec.709 primaries than 170m I'm wondering if they'd be a better choice, or even if it'd be better not to convert them at all for playback using a HD display.
Cheers.

Edit: I deleted the rest of this post after reading a bit more. Continued next post though.....

[hello_hello]

According to Wikipedia, analog PAL was broadcast with a gamma of 2.8, hence the 470BG transfer function.
Although a citation on wikipedia led me to a PDF with a list of analogue broadcast gammas and a note for PAL which says:
"(13) Assumed value for overall gamma approximately 1.2. The gamma of the picture tube is defined as..."

In the section on rec.709 transfer characteristics (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics) on Wikipedia it says:
"Old CRTs had a EOTF of 2.35 pure gamma"
yet analogue NTSC was broadcast with a gamma of 2.2.

Somewhere on wikipedia there was a citation that led me to this page:
https://www.chromapure.com/colorscience-gamma-new.asp
"The combination of these two opposite nonlinear luminance curves—camera gamma at the production end and display gamma at the device end—results in a linear system gamma of 1.0, which is what we want. However, when viewing material in a dim environment, it is generally thought desirable to have a system gamma that is slightly higher: somewhere between 1.1 and 1.2 is most often quoted figure."

Obviously the "system gamma" of 1.2 continued into the digital era, but from what I've read I assume there was no standard way to achieve it before BT.1886. I can't get my head around how it's anything but a display gamma though, and as such nothing you'd apply when doing a colorspace conversion, at least not for SDR<->SDR conversions. If you do, doesn't it result in an OOTF of 1.0 instead of 1.2, or depending on the direction greater than 1.2, or something else entirely?

In fact, now that I read it again....
rec.709 transfer characteristics (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics)
"Rec. 709 doesn't specify the display EOTF (electro-optical transfer function) which describes how HDTV displays should convert the non-linear electrical signal into linear displayed light, that was done in BT.1886."

[Dogway]

When I said after a color conversion I'd expect the video to display the same way, I realise the colors have to change, but I was looking at it in terms of a matrix conversion where if you convert from 709 to 601 for downscaling the colors change, but they display the same way (ignoring the difference in primaries).

Change in what terms, colors (primaries) or tones (transfer)? For transfer I'm going to perform a few changes I will list below, for color it's going to change no matter what because AvsPmod nor any other GUI for AVS are color managed (like Photoshop or Firefox are), so to visualize all your videos and having them match color space-wise you should append Display_referred() to the end of the script ideally with a calibration-LUT referenced, comment it before encoding though.

As for the issue with gamma, I will change all OETF (read "inverse EOTF", will deal with naming later) and EOTF to 1886 as most content we work with are consumer delivery media. To get the scene-referred linear signal one should do an inverse 1886 EOTF, then a 1886 to 170M (or according acquisition gamma) OOTF (misnamed in above post as EETF).

This is going to clash and go against with many of the current source loaders and color conversion plugins frame properties support which indicate transfer characteristics IDs based on matrix and not on consumer media standard EOTF. And will also require a 32-bit pipeline to avoid crushing blacks as 1886 has not a linear part to protect those areas (16-bit is not enough), I will try to force 32-bit in such cases only for the required parts to save performance.

To illustrate:
709-Camera (170M: Acquisition) -> Linear (post-production) -> 1886 EOTF (delivery)

Depending on what linearization process was used in post-production one would get scene-referred linear signal with a simple inverse 1886 EOTF, or an additional OOTF should be used. Otherwise all you get is electrical-linear, not scene-referred.

For color space conversion (your fmtc example) and all processing electrical-linear is sufficient, as that's the linear space where (I think) all post-production is performed (assuming they linearize by inverse 1886 EOTF).

What does "the encoding function of image sources is adjusted" mean? Not a rec.709 OETF?

That implies they use a simple inverse 1886 EOTF and not an inverse 709-camera (170M OETF technically) because by default their monitors should be calibrated to 1886. So they simply get linear by reversing a Display 1886 EOTF without the need to add OOTF and such.

OOTF of 1.2 is in case you want to get "scene-referred" linear, or undo the dim surround adaptation to re-adjust to an EOTF of 2.2 or 2.6.

Some remarks from you latest post

(13) Assumed value for overall gamma approximately 1.2. The gamma of the picture tube is defined as...
It means an end-to-end absolute gamma after OETF+EOTF, because a dim surround requires a higher gamma.
In the section on rec.709 transfer characteristics on Wikipedia it says:
"Old CRTs had a EOTF of 2.35 pure gamma"
yet analogue NTSC was broadcast with a gamma of 2.2.
That would make an end-to-end absolute gamma of 1.07 which is within reason, some CRTs were 2.4 or even 2.5. Technically they should set the programming to a 170M gamma.

results in a linear system gamma of 1.0, which is what we want.
We surely don't want an absolute gamma of 1.0. TV systems were designed to be played from the evening onwards, that's why the CRTs gamma were dialed to 2.4 and the concept of "dim surround" which is a night living room with lights on.


I will be uploading an update later today so you can tell me if it makes better sense to you (it does so for me).

[DTL]

"Depending on what linearization process was used in post-production one would get scene-referred linear signal with a simple inverse 1886 EOTF, or an additional OOTF should be used. Otherwise all you get is electrical-linear, not scene-referred."

It looks using or not OOTF part also may visibly affects the other processing attempt to perform in 'linear' like scaling -
https://forum.doom9.org/showthread.php?p=1970995#post1970995 . May be only jpsdr plugin may switch on/off OOTF part to see the difference. And many other plugins for convert to 'linear' can not.

[Dogway]

I'm pretty sure all SDR content today is mastered to 1886 2.4 gamma for consumer media so "what you see is what you get". But back in the day (pre-grading ages) it was about playing with gamma and let the end device do the heavy lifting, therefore encoding with 170M gamma with a linear part in the foot region to "minimize noise in the darker areas of the image". Then it was naturally shown with 2.3-2.4 power gamma by the CRT Electron Gun.

@DTL: Just noticed some issues with internal scalers and float bitdepth, overshoots are not clipped so they can create some NaN pixels later on. I will have a look at your linked post. I recall running some tests some time ago.

This leads to some below 0 values:
Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
bicubicresize(2048,2048,0,0.75)

[DTL]

Below 0 is normal for undershoots because AVS float format is in 0.0 .. 1.0 nominal range as I read at forums - not 16.0..235.0 as may be expected. So any undershoot with 0.0 black will go below zero in the negative numbers.
I check

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
bicubicresize(2048,2048,0,0.75)

ColorYUV(gain_y=-100, off_y=50)

ConvertBits(8)

It looks like normal over/undershoots but no significant bugs visible if even NaN values exist somewhere (?). In bad case NaN may converted to integer in some really buggy 8bit values like 0 or 255 and cause gross distortions.
I think the too low undershoots like -1.0 float will be clipped to 0 integer. Same with too high overshoots to 255 8bit.

Good linear scaler must not clip any over/undershoots if possible. So using float allow to keep over/undershoots of any amplitude. And integer scaler will clip to 0 and MAX_INT unsigned or to (-)MIN_INT and MAX_INT signed.

[Dogway]

Depending on the following expression I can get white NaN pixels (from the -0.1 values). This is going to be normal for linear resizing so I don't know if a clamp argument would be beneficial in scalers... or something along the lines of "don't change sign".

Not sure how to handle this except for avoid resizing in float.

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
propSet("_ColorRange",0)
ConvertBits(32)
bicubicresize(2048,2048,0,0.75)
ex_Luma_Rebuild(5.0, 0.03, tv_in=false)

[kedautinh12]

Hi Dogway, your deep_resize proplem with 1440i, i tried but error with both gpuid=0 and -1.

My script:
AnimeIVTC(mode=1)
deep_resize(1920,1080)

I got error NNEDI3CL: field must be 0 or 1 when dw=True

and with this script:
AnimeIVTC(mode=1)
deep_resize(1920,1080, gpuid=-1)

I got video don't match with audio

my example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

[DTL]

"I can get white NaN pixels (from the -0.1 values)."

If you think there is some bug around zero or in going negative - the float allow to add some 'big' positive offset like 10.0 to 'nominal' 0.0..1.0 range before operation and subtract after. I think it should completely avoid using any negative values and zero crossing at resampling engine.
This also works without visible distortions

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
ColorYUV(off_y=50000)
bicubicresize(2048,2048,0,0.75)
ColorYUV(off_y=-50000)
ColorYUV(gain_y=-100, off_y=50)
ConvertBits(8)

[Dogway]

Hi Dogway, your deep_resize proplem with 1440i, i tried but error with both gpuid=0 and -1.

My script:
AnimeIVTC(mode=1)
deep_resize(1920,1080)

I got error NNEDI3CL: field must be 0 or 1 when dw=True

and with this script:
AnimeIVTC(mode=1)
deep_resize(1920,1080, gpuid=-1)

I got video don't match with audio

my example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

Interlaced isn't supported in deep_resize only progressive, try also to check frame properties.

Thanks DTL, yes I was trying to avoid adding an additional calls like preshaping or clamping. It's for the scaling spaces in ConvertFormat (gamma, linear, sigmoid, log)

[kedautinh12]

Interlaced isn't supported in deep_resize only progressive, try also to check frame properties.

Thanks DTL, yes I was trying to avoid adding an additional calls like preshaping or clamping. It's for the scaling spaces in ConvertFormat (gamma, linear, sigmoid, log)

But i used to animeITVC to deinterlace

[kedautinh12]

I used to deep_resize with other interlaced after deinterlace with animeITVC and got no error.

[Dogway]

@kedautinh12, can you check frame properties after AnimeIVTC? I don't have the script and its dependencies installed so I can't check but for me your clip works by deinterlacing with ex_bob(nnedi3=true).
Try adding propSet("_FieldBased",0) before deep_resize()


It looks using or not OOTF part also may visibly affects the other processing attempt to perform in 'linear' like scaling -
https://forum.doom9.org/showthread.php?p=1970995#post1970995 . May be only jpsdr plugin may switch on/off OOTF part to see the difference. And many other plugins for convert to 'linear' can not.

OOTF looks to be as simple as o_transfer/i_transfer. In any case I still don't support HDR in ConvertFormat, HLG nor PQ so can't help with your issue.


EDIT: hello_hello, you can download now updated TransformsPack here (https://github.com/Dogway/Avisynth-Scripts/blob/master/TransformsPack%20-%20Main.avsi). Default OETF and EOTF have been changed for consumer delivery spaces. I might need to add more in the future.

I also created a new function OOTF() in TransformsPack - Transfers. It will take a single remap gamma value in OOTF, but you can also specify OETF and EOTF gamma values as floats, or their transfer names as strings. For those transfers with piece-wise functions (a linear part towards zero) a minimization algo was implemented to find the power law match, so for example for sRGB it would minimize to 2.223. This is faster than linearizing then gamma encoding back.

On another note I'm finally updating the SMDegrain documentation, half done already.

[kedautinh12]

@kedautinh12, can you check frame properties after AnimeIVTC? I don't have the script and its dependencies installed so I can't check but for me your clip works by deinterlacing with ex_bob(nnedi3=true).
Try adding propSet("_FieldBased",0) before deep_resize()

Oh, it's work with propSet("_FieldBased",0) before deep_resize(). Thanks

[hello_hello]

Well... I've tried, but I just don't understand the world anymore..... :(

720p Rec.709 YV12 source.
No Avisynth+ frame properties.
Transforms Pack 1.0 RC55

ConvertBits(16)
ConvertToDoubleWidth()
Matrix(From=709, To=601, Bitdepth=16)
ConvertFromDoubleWidth()
Spline36Resize(640,360)
https://i.ibb.co/zx4gq2g/1.jpg

ConvertToYUV444()
ConvertBits(16)
ConvertYUVtoLinearRGB(Color=2)
ConvertLinearRGBtoYUV(Color=4)
ConvertBits(8)
ConvertToYV12()
Spline36Resize(640,360)
https://i.ibb.co/dt886c9/2.jpg

fmtc_bitdepth(bits=16)
fmtc_resample(css="444")
fmtc_matrix(mat="709", bits=16)
fmtc_transfer(transs="709", transd="linear")
fmtc_primaries(prims="709", primd="601-625")
fmtc_transfer(transs="linear", transd="601")
fmtc_matrix(mat="601", bits=16)
fmtc_resample(640,360,css="420")
fmtc_bitdepth(bits=8)
https://i.ibb.co/191WJpG/3.jpg

ConvertFormat(640,360)
https://i.ibb.co/VHKC1Dc/4.jpg

ConvertFormat(640,360, OETF="170m", EOTF="170m")
https://i.ibb.co/3dGfynG/5.jpg

ConvertFormat(640,360, EOTF="170m")
https://i.ibb.co/CBN1ZLY/6.jpg

Bugs be here?
Display_Referred("1886")
https://i.ibb.co/PTPxJzd/7.jpg

Display_Referred()
ConvertFormat(640,360)
https://i.ibb.co/FgXV3j1/8.jpg

[Dogway]

There's a regression when I repurposed Matrix_coef() to retrieve primaries for XYZ_to_RGB() a few weeks ago so it's reading 470M instead of 170M, hold on a bit. I've been thinking for some time on a manner to restructure the matrices vertically since I'm going to add many more but still haven't come with a solution...

Display_referred() should be working. You don't specify the transfer but the color space, if your source is "170M" and your display is calibrated to Rec.709 with 1886 transfer set:
Display_Referred ("170M","709") # 709 or sRGB whatever your display is calibrated against
Ideally you should set a LUT profile in the "profile" argument.


EDIT: @hello_hello, updated TransformsPack to RC56 with the above fix. I can't follow your first two examples but for fmtconv you might want to use "601-525" which corresponds to "170M". And as I commented a few posts back you want to use 1886 transfer for going to and from linear since all/most media is delivered in this ODT (display referred).

[ENunn]

Sorry for the late response.

I borked it (QTGMC), fixed now hopefully (along ResizersPack). In any case previous version (3.85) should be working.

My guess is that something is not up to date...
Everything was up to date as of my last post. I just downloaded the pack again just to be safe and the issue still happens.

As per your comments everything runs fine until the SMDegrain call?
Yes, and if I move the converttoyuv422/convertbits/tweak/convertbits line after SMDegrain, the issue doesn't happen.

Are you on x86 or x64?
x64

Another thing, try with str=1 or str=0, str=0.8 invokes ex_retinex() which is good but that might be causing you some issue.
Looks like that fixed it.

[Dogway]

@ENunn, that's very strange specially after the last fix for ex_retinex(), simply try directly:
ex_retinex(lo=80, tv_in=true, tv_out=false)
And just in case revise you are on latest vsTCanny plugin version.

[ENunn]

@ENunn, that's very strange specially after the last fix for ex_retinex(), simply try directly:
ex_retinex(lo=80, tv_in=true, tv_out=false)
And just in case revise you are on latest vsTCanny plugin version.
Tried before and after SMDegrain and without SMDegrain and the issue is still there, plus it makes the image much brighter as well.

I updated vsTCanny and it's still there.
https://i.imgur.com/JNxq8z4.png
https://i.imgur.com/zAIC8Il.png

[hello_hello]

Dogway, is there a RC56 version of Transforms Pack - Models? It's just that I'm only producing "no function named Matrix_coef" errors with ConvertFormat since updating the other two scripts.

I can't follow your first two examples but for fmtconv you might want to use "601-525" which corresponds to "170M".

1. Matrix-only conversion with HDRMatrix.
2. 709 -> 601-625 conversion with HDRTools.

What's the logic behind always converting to NTSC primaries?
I was pondering over whether "170M" should still be used to describe a transfer function earlier, which led me to discover... unless the list is incomplete or I'm blind.... it no longer does for h265. http://www.vapoursynth.com/doc/functions/video/resize.html
And as rec.601 is the matrix for both digital "PAL" & "NTSC", the only reason I can think of for using 170M or 480bg is to differentiate between them.
601_525, 601_625 & 601 cover all the bases, although for CropResize I went with 601N, 601P and 601 even though the NTSC and PAL implication isn't accurate.

For a while I was fairly anal about converting the primaries to 601, and I generally chose 601_625 because they're closer to 709, but if HD displays and players don't concern themselves with the primaries and simply assume 709, which I suspect they mostly do, a matrix-only conversion might be better.

And as I commented a few posts back you want to use 1886 transfer for going to and from linear since all/most media is delivered in this ODT (display referred).

I'll take your word for that, but I still can't get my head around it as everything I've read indicates it's only a display transfer function, and because 1886 is designed to factor in the black (and white?) levels of a calibrated display, and because the display used for mastering is an unknown, and because the definition of "deliver" might be one that doesn't imply it's not converted to 709 (scene) before it reaches my TV, and because to me it defeats the purpose of 1886, but what do I know.....

[Dogway]

TransformsPack - Models was updated here (https://github.com/Dogway/Avisynth-Scripts/commit/e093a2c428078ba1dd134716cd8f90d5fdd188c4). I simply forgot version update.
What's the logic behind always converting to NTSC primaries?
You mean NTSC matrix coefficients? Both PAL and NTSC inherited the matrix coefficients of 470M (FCC) for historical reasons. Read here (https://github.com/Dogway/Avisynth-Scripts/blob/75ac682b5559a426d43d1ca7abda8574ffa0f341/TransformsPack%20-%20Main.avsi#L1854).
I was pondering over whether "170M" should still be used to describe a transfer function earlier, which led me to discover... unless the list is incomplete or I'm blind.... it no longer does for h265. http://www.vapoursynth.com/doc/funct...eo/resize.html
And as rec.601 is the matrix for both digital "PAL" & "NTSC", the only reason I can think of for using 170M or 480bg is to differentiate between them.

H.265 ITU paper calls the transfer function by their related matrix, they are inconsistent though, they call the 2020 transfer ST.2084 which is the (SMPTE) paper that defines the 2020 space characteristics. Yes, a mess, they mix ITU, IEC, FCC, and SMPTE naming standards. I say, stick to one or two, you can read here some of my rant (https://forum.doom9.org/showthread.php?p=1957275#post1957275). To start with, the first time (or one of the firsts) the 170M transfer was defined was in SMPTE ST 170 in 1994, your linked table makes use of this transfer for 709, 601, 2020_10 and 2020_12 and state "functionally the same", yes, another mess. "Functionally the same" reads as different but yields the same result, which is not true, they employ not "functionally" but the exact same transfer, so I gave it a single name.
Now why did I keep 470BG transfer (2.8 gamma)? because in TransformsPack I allow you to do whatever you want to. Limited TV range for float? Also OK. AP0 primaries? Also OK (not listed in ITU)
Another aspect is the matrix coefficient table, so RGB "is" a matrix ? ICtCp is a matrix? YCoCg? Another mess. They are color models, and the said "matrix" coefficients only refers to the YCbCr model matrix coefficients, not the ICtCp, not the YcCbcCrc or any other. No wonder you are confused, not even the standards make it right. I do my best to add comments on my scripts to give some background but I don't adhere strictly to ITU or any other standard.
For a while I was fairly anal about converting the primaries to 601, and I generally chose 601_625 because they're closer to 709, but if HD displays and players don't concern themselves with the primaries and simply assume 709, which I suspect they mostly do, a matrix-only conversion might be better.
I want to think they do convert from 170M for SD, the same reason they still keep deinterlacing capabilities, now I don't know what they assume for 640x360, maybe you should scale it based on height (854x480 or 1024x576).
I'll take your word for that, but I still can't get my head around it as everything I've read indicates it's only a display transfer function, and because 1886 is designed to factor in the black (and white?) levels of a calibrated display, and because the display used for mastering is an unknown, and because the definition of "deliver" might be one that doesn't imply it's not converted to 709 (scene) before it reaches my TV, and because to me it defeats the purpose of 1886, but what do I know.....
You can also take cretindesalpes' word for that, as I found an example (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L177) yesterday in the docs.
The display used for mastering DVD/BD consumer media is calibrated to 1886, they make different (grade) trims depending on delivery media and it's always display referred (for the last 20 years at least). The workflow typically involves an IDT (OETF) -> Log/Linear (trim pass under EOTF proof) -> ODT (EOTF). So they work in log or linear space under an EOTF (1886) viewing transform.
To be more specific, the input device might be calibrated so the IDT could be transformed from a custom (unknown) profile, and similarly the EOTF viewing transform is also a mastering monitor profile characterized against 1886. When encoding the EOTF into the image instead you don't use your display profile (with custom 1886 settings) but a generic one that assumes a perfect imaginary display with 0 black, so in essence a power law gamma of 2.4 and a generic color space with known primaries, like 709. This makes it possible to "undo" the transfer and primaries and convert to your display profile in case it's calibrated, or play very close to intended in case it's not calibrated

--------------------------------------

@ENunn, what do you mean with "the issue is still there, plus it makes the image much brighter as well." Either the issue is present or it's making the image brighter which means it's working fine (that's retinex) if it shows your image black or as your above example, then there's an issue. But I'm not experiencing it with FFMS2 loader.

[hello_hello]

TransformsPack - Models was updated here (https://github.com/Dogway/Avisynth-Scripts/commit/e093a2c428078ba1dd134716cd8f90d5fdd188c4). I simply forgot version update.

I didn't update it because the version number was the same. Obviously I should have.
It's working now so I'll have a play with it again soon.

You mean NTSC matrix coefficients? Both PAL and NTSC inherited the matrix coefficients of 470M (FCC) for historical reasons. Read here (https://github.com/Dogway/Avisynth-Scripts/blob/75ac682b5559a426d43d1ca7abda8574ffa0f341/TransformsPack%20-%20Main.avsi#L1854).

No I was referring to the primaries, as you said I should use 601_525 with fmtconv rather than 601_625. It's the fmtconv method for choosing the SD primaries.

H.265 ITU paper calls the transfer function by their related matrix, they are inconsistent though, they call the 2020 transfer ST.2084 which is the (SMPTE) paper that defines the 2020 space characteristics. Yes, a mess, they mix ITU, IEC, FCC, and SMPTE naming standards. I say, stick to one or two, you can read here some of my rant (https://forum.doom9.org/showthread.php?p=1957275#post1957275). To start with, the first time (or one of the firsts) the 170M transfer was defined was in SMPTE ST 170 in 1994, your linked table makes use of this transfer for 709, 601, 2020_10 and 2020_12 and state "functionally the same", yes, another mess. "Functionally the same" reads as different but yields the same result, which is not true, they employ not "functionally" but the exact same transfer, so I gave it a single name.

Now why did I keep 470BG transfer (2.8 gamma)? because in TransformsPack I allow you to do whatever you want to. Limited TV range for float? Also OK. AP0 primaries? Also OK (not listed in ITU)

I think it's fine to keep the 470bg transfer option, although given it was an analog-only thing it possibly adds to the confusion.
That's why I think replacing 170m with 601 (in respect to naming) as the transfer curve and matrix for digital is a good idea because if you read the wikipedia page (Rec. 601) it was intended for both PAL and NTSC and was later updated to include both the PAL and NTSC primaries.
Some plugins (colormatrix) use 601 as the SD matrix, while some (avsresize) use it for the transfer curve but not for the matrix.
Of course because the primaries are different for PAL and NTSC you do need a way to differentiate between them.

Another aspect is the matrix coefficient table, so RGB "is" a matrix ? ICtCp is a matrix? YCoCg? Another mess. They are color models, and the said "matrix" coefficients only refers to the YCbCr model matrix coefficients, not the ICtCp, not the YcCbcCrc or any other. No wonder you are confused, not even the standards make it right. I do my best to add comments on my scripts to give some background but I don't adhere strictly to ITU or any other standard.

For RGB to have a matrix does seem meaningless, but from our perspective it'd be useful if you could use it to correct RGB colorimetry without having to convert to a different colorspace and back. For example, if YUV was converted to RGB using rec.709 instead of rec.601, it'd be nice to be able to correct it this way (using an avsresize type example)
709:srgb:170m=>601:srgb:170m
but I don't think any plugins will do that sort of thing for RGB without a format conversion in between. Maybe there's a reason for that I'm unaware of.

I want to think they do convert from 170M for SD, the same reason they still keep deinterlacing capabilities, now I don't know what they assume for 640x360, maybe you should scale it based on height (854x480 or 1024x576).

640x360 was just a 16:9 resolution I chose because I'd originally planned to add the pictures to my post, but when there ended up being several of them I posted links instead.

You can also take cretindesalpes' word for that, as I found an example (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L177) yesterday in the docs.
The display used for mastering DVD/BD consumer media is calibrated to 1886, they make different (grade) trims depending on delivery media and it's always display referred (for the last 20 years at least). The workflow typically involves an IDT (OETF) -> Log/Linear (trim pass under EOTF proof) -> ODT (EOTF). So they work in log or linear space under an EOTF (1886) viewing transform.
To be more specific, the input device might be calibrated so the IDT could be transformed from a custom (unknown) profile, and similarly the EOTF viewing transform is also a mastering monitor profile characterized against 1886. When encoding the EOTF into the image instead you don't use your display profile (with custom 1886 settings) but a generic one that assumes a perfect imaginary display with 0 black, so in essence a power law gamma of 2.4 and a generic color space with known primaries, like 709. This makes it possible to "undo" the transfer and primaries and convert to your display profile in case it's calibrated, or play very close to intended in case it's not calibrated

I understand what you're saying, but it seems to cover what production companies can do with delivered content, not necessarily how it ends up being streamed to my TV. I was looking at the Netflix delivery specs (https://partnerhelp.netflixstudios.com/hc/en-us/articles/214806618-Netflix-Branded-Delivery-Specifications-v4-1) yesterday, and for HD SDR it's:
10 bit
ITU-R BT.709 / D65 / ITU-R BT.1886
(Gamma 2.4)

So then I checked out the packaging requirements:
All deliveries to Netflix must be compliant to either SMPTE ST 2067-21:2016 or SMPTE ST 2067-21:2020 Interoperable Master Format (IMF) Application #2E.

Okay, so what does SMPTE ST 2067-21:2020 (https://ieeexplore.ieee.org/document/9097487) say?
COLOR.1
Mapped as specified for 625-line systems in Section 2.6 of Recommendation ITU-R BT.601-7.
COLOR.2
Mapped as specified for 525-line systems in Section 2.6 of Recommendation ITU-R BT.601-7.
COLOR.3
Mapped as specified in Section 1 of Recommendation ITU-R BT.709-6.

Note: In Recommendation ITU-R BT.601 and Recommendation ITU-R BT.709, the signals... ...correspond to gamma pre-corrected signals.

The above seems to serve as support for only using 601 too, but off to ITU-R BT.709-6.
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
Overall opto-electronic transfer characteristics at source
It doesn't seem to copy and past properly but it's the standard 709 OETF with the following footnote:
(1) In typical production practice the encoding function of image sources is adjusted so that the final picture has the
desired look, as viewed on a reference monitor having the reference decoding function of Recommendation
ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.

Just kill me now. Could "the encoding function of image sources" mean "the encoding function of the source video when it's decoded"?
It won't install on this PC, but sometime soon I'm going to check out Davinci Resolve to see what it actually does. I've looked at a few instructional videos and what they show is what you've said, with the exception of rendering when choosing rec.709 as the output colorspace. There, the transfer curve used wasn't really clear.

[Dogway]

although given it was an analog-only thing it possibly adds to the confusion.
That's why I think replacing 170m with 601 (in respect to naming) as the transfer curve and matrix for digital is a good idea because if you read the wikipedia page it was intended for both PAL and NTSC and was later updated to include both the PAL and NTSC primaries.

You are not going to see the 470BG curve referenced anywhere today since it's considered "deprecated" by current standards, so all the references you are going to see for PAL transfer is the original 170M curve. I even had a hard time finding its alpha and phi values.

I'm adding or planning to add all sorts of analog models and spaces, for example YIQ, YPbPr and so on. NTSC 1953 was also analog only and it's included everywhere (for some reason).

My design choice is similar to avisynth's "give people enough rope to hang themselves", replacing "hang" with the chance of being more capable or experimental, all while keeping a good user experience and defaults.

it'd be useful if you could use it to correct RGB colorimetry without having to convert to a different colorspace and back
YCbCr is not a linear model, so you can't change color space without going to RGB and back.
709:srgb:170m=>601:srgb:170m
That line doesn't make sense to me, change matrix while keeping primaries? sRGB transfer for YUV?

Could "the encoding function of image sources" mean "the encoding function of the source video when it's decoded"?
It's only a convoluted way to say, grade your (decoded -as in inverse OETF-) footage until it looks fine in your 1886 calibrated reference monitor.

[ENunn]

@ENunn, what do you mean with "the issue is still there, plus it makes the image much brighter as well." Either the issue is present or it's making the image brighter which means it's working fine (that's retinex) if it shows your image black or as your above example, then there's an issue. But I'm not experiencing it with FFMS2 loader.

The issue is still present, as shown in my first screenshot.

I loaded it with ffms2, and the issue is still there. (https://imgur.com/a/gdQShAS)

EDIT: It has something to do with the tweak line. I removed the convertbits parts and the issue persists. I also tried another tweak plugin, SmoothTweak, and the issue happens there as well. Tweak before SMDegrain causes the issue, tweak after SMDegrain does not have any issues.

[hello_hello]

You are not going to see the 470BG curve referenced anywhere today since it's considered "deprecated" by current standards, so all the references you are going to see for PAL transfer is the original 170M curve. I even had a hard time finding its alpha and phi values.

All I was trying to say is 480bg is analog, as I assume was 170M originally, then along came rec.601 for digital which once again I assume has the same transfer function as 170M, but either way, rec.601 replaced both 170M and 480bg for digital video so to me it makes sense if 601 was used to describe the digital SD matrix and transfer function. Just as an example, that's what fmtconv does for matrix, there is no 170M option, and for transfer it's the same, except 480bg is still an option if you want to use it. For the SD primaries there's several presets for choosing them, but my preference is to stick with the 601 theme and use the 601_525 and 601_625 presets for digital "NTSC" and "PAL".

Lots of options is good, but for presets that'd be my preferred naming scheme.

YCbCr is not a linear model, so you can't change color space without going to RGB and back.

That line doesn't make sense to me, change matrix while keeping primaries? sRGB transfer for YUV?

Isn't changing the matrix while staying in YUV what colormatrix does?
My example probably should have looked like this
709:srgb:709=>601:srgb:170m
but it was in reference to my fantasy for being able to correct the incorrect matrix used when converting YUV to RGB without changing color space. So it'd be RGB in and RGB out. For the above example you'd have RGB that was converted from YUV using the 709 matrix when it should've been 601, so in my fantasy it would correct that while staying in RGB.
Maybe it's something that can't actually be done, although I was under the impression that's what the following would do for HDRTools, but looking at it again now I'm not really sure what it does. I think it's just changing the primaries.
ConvertToRGB(matrix="rec709")
ConvertRGBtoXYZ(Color=2)
ConvertXYZtoRGB(Color=4)

It's only a convoluted way to say, grade your (decoded -as in inverse OETF-) footage until it looks fine in your 1886 calibrated reference monitor.

Well it does say "the encoding function of image sources is adjusted", and if it's referring to the source video it shouldn't apply if the source video was 1886. Anyway, it's obviously just guessing because I don't actually know.

[Dogway]

601 is too ambiguous, for SD I follow the SMPTE nomenclature because they were the reference standard at the time and CCIR (now ITU) was behind. They simply knew what they were doing. All SD related content from ITU is badly copy/pasted from SMPTE standards or directly don't have a paper for the recommendation and simply refer to the SMPTE.

The good news in ConvertFormat is that it supports aliases, so if you like "601" or "601_525" (to remove ambiguity) simply input that and it will retrieve the best match. And the property IDs are unified so they will be the same for fmtconv, TransformsPack, avsresize, etc I expanded them though.

Isn't changing the matrix while staying in YUV what colormatrix does?
The use case for ColorMatrix is such a corner case scenario that I haven't even implemented it.
Read here (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L163).
It shouldn't be a thing really. My question is, how do you know it's using the wrong matrix but the correct primaries?

Well it does say "the encoding function of image sources is adjusted"
You shouldn't read too much into it, they are full of inconsistencies otherwise we wouldn't be going rounds in Doom9 about the topic. You don't "adjust" a transfer function, you choose it according to your delivery choice and master monitor.

[madey83]

Hello,

Could you advice how to setup denoiser like SMDegrain to clear this out?
https://i.postimg.cc/cCW67vT2/example.png

EDIT:
on the screen there is less noise than on the video.

i tired these without any spectacular effects:

SMDegrain(tr=2, thSAD=500,thSADC=100, thSCD2=80, contrasharp=false, refinemotion=true, truemotion=false, search=4, subpixel=3, Chroma=true, plane=4, LFR=false, DCTFlicker=false)

### Dogway this is a good compromise between quality and speed
Code:
smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=700,LFR=2,contrasharp=false,refinemotion=true)
smdegrain(tr=2,mode="MDegrain",blksize=32,thSAD=400,LFR=false,contrasharp=true,refinemotion=true)

EDIT:
i've just adjusted in the latest version of SMDegrain below line acordingly:

(prefilter== 5) ? pref.ex_KNLMeansCL(a=3,s=3,d=3,h=9.0,wmode=2,chroma=chroma,gpuid=gpuid,LFR=0*(nw/1920.)).ex_boxblur(0.5, mode="weighted", UV=Chr)

and got some promissing results, but encode speed drop off beacuse CPU usage is only for about 70%.

[Dogway]

I don't think you need to run the double call, I don't see the source that grainy (300 style).

Simply use a good prefilter, maybe BM3D, and raise 'tr' a bit. I don't know the reason to tweak thSCD2, also everything else is already the default so you can omit.

KNLMeansCL runs in GPU with OpenCL, you can also try DGDenoise which runs over CUDA.