x265 parameters to retain image grain

[vhelp]

I am struggling with this, trying to retain the image grain for aesthetics purposes in vhs after analog lossless capturing from this medium.

Note, I normally encode my videos with the following x265 parameters

avs4x265 -P x265 --preset ultrafast --frames 2561 --crf 17 --ssim --csv video.crf.17.LQ.tune[grain].ultrafast.hevc

But with vhs, you want to keep as much detail as possible. That usually requires a slightly larger filesize, which I'm ok with. I would prefer to keep the aesthetics of vhs as much as possible.

So, after some searches, I learned that x265 has a parameter for *grain* under the parameter: --tune grain

And I updated the script to that:

avs4x265 -P x265 --preset ultrafast --frames 2561 --crf 17 --ssim --csv --tune grain video.crf.17.LQ.tune[grain].ultrafast.hevc

But, after adding that parameter to the script (above) the video will bloat 3x to 4x larger in filesize and the video is as poor a quality as with not using my original x265 script above, without --tune grain. I don't want to smooth the video. That is what this setting is doing. I already get that w/out the --tune grain.

So I would like to ask, what are the parameters to use to retain as much grain as possible in x265 ?

[sophisticles]

I would use a slower preset, a lower crf (if you must use crf), or maybe I would denoise/degrain with a filter and then use a different filter to add grain, maybe try a different encoder as x265 in the latest builds seems to be focusing on smoothing out the picture more than in previous builds, perhaps not re-encode it at all.

BTW, why are you specifying the number of frames?

[KarMa]

But, after adding that parameter to the script (above) the video will bloat 3x to 4x larger in filesize and the video is as poor a quality as with not using my original x265 script above, without --tune grain. I don't want to smooth the video. That is what this setting is doing. I already get that w/out the --tune grain.

So I would like to ask, what are the parameters to use to retain as much grain as possible in x265 ?

I get good results with --tune grain, and see the file size about double for the same CRF without --tune grain. 3x-4x bigger is not what I experience, though I don't normally go below 20 with x265 CRF and tend to use Medium or Slow preset. I also see a very noticeable retention of the original grain and detains, compared to the default. But the tune grain has the problem of retaining more HEVC artifacts at higher CRFs, where the default tends to just smear everything.

Are you visually comparing, or just using the SSIM data?

You should probably using preset Medium at least.

BTW, why are you specifying the number of frames?

Guess he is testing and wants the same number of frames in all his tests.

[vhelp]

I'm using --frames because that's what was required way back in the old ver .1 days, I think. I am encoding short snippets here and there. It is a default parameter used in a gui app to encode videos. I just change the total frame number to match the video I am encoding at the time.

Are you visually comparing, or just using the SSIM data?

Yes. I have an application (that I am slowly developing) I'm doing work in to help me review videos that I capture and encode, to show various attributes like (r/g/b, y/u/v, h/l/s, an enlarged 16x16 grid of pixels to show me the effects or changes an encode or color change made from my tweaking or encoding, ...).

I am using ultrafast because i am on a slow dell inspiron i3 6GB laptop win7-64 from 2010, though faster than my desktop pc, amd dual core 2GB winxp-32. But I do tests with other --presets like slow (10min per 1min clip) and even placebo (1hr per 1min clip) but it is difficult to make changes in params with these presets when it takes so long, you tend to wanna give up. I wish I could get something really fast in a laptop or tiny device that just encodes video so I could take advantage of testing x265 more thoroughly. But I don't know pc's and processors all that well. Anyway. I can only use 720x480 videos at this speed. And its all I have anyway.

Am I miss-using SSIM in some way ?

Do I need to start using (specific) parameters outside of --presets now?
Are there any special params that I should start using to help with grain retention?

Thank you for any advice or suggestion.

[KarMa]

I've been using x265 since 1.3-1.4 and don't think I have ever used --frames.

Recently I started using the comparison function in Staxrip to making comparing videos easier, after sophisticles brought that program up in a different x265 thread. With the tool it just uses Avisynth to server the video in tabs, and can just click the tabs to jump back and forth between the videos at any given point.

In Staxrip you can find it under Tools-->Advanced--->Video Comparison

The only problem with it is that it can't open .avs scripts for comparison, or I'm doing something wrong. So if I have a source that needs deinterlacing, I would need to deinterlace it into a lossless format to compare it to a deinterlaced HEVC version for example. AvsPmod is also great for comparisons by jumping between tabs and certainly supports .avs scripts.

Without videos or at least pictures, we are just going to be guessing what your problem is. There should be a decent difference between --tune grain and the default.

I'd honestly stick with x264 for VHS/DVD content for now. Especially for grain.

[LigH.de]

Pipe bridge tools like avs4x26* will probably add the number of frames on their own, to enable x265 printing a progress estimation, because raw YUV has no header, and Y4M headers don't contain a number.

Grain tuning has been tweaked in recent versions of x265 quite often. It changes the behaviour rather severe, just search for "sao" (smooth all objects). IIRC, developers even introduced new internal parameters during version 2.0 to handle this case.

[vhelp]

@ karma

Hopefully, I can be of help to you (or anyone) this time around.

You can open the .avs scripts in staxrip via virtualdub's .vdr server. This is my only way I know how to open "virtualdub processed" video back into avisynth for review or further processing. If avisynth won't accept the .vdr file (I was having that problem the past week) then you didn't install the "AVIFile handler". Go back to the virtualdub folder and run the auxsetup.exe file. Avisynth should now open your .vdr file. If it doesn't, (I was having that trouble myself) then locate virtualdub verion 1.6 and run that auxsetup.exe file. It worked for me, and now I can open vdr files in avisynth via AVIsource().

[vhelp]

LigH I am pretty current and don't think I am missing any new feature, function or enhancement for "grain" handling. The version I've been using in my current tests was 2.0+45 though I can quickly revert back and forth between them. I just want to retain as much of the grain as possible because (as KarMa pointed out) the video mostly shows a "smeared" look in those areas with/without --tune grain.

Now, of course there is a difference between "film grain" and "vhs grain". But as with film grain, for vhs, and its limited detail, the grain in that medium is in the form of what the capture card produces. All the bi-products that go into analog capture from the vcr, the cables, down to the capture card and into an avi. In my opinion, it is crucial that we maintain those pieces that help to give it that aesthetic for vhs transfers. I'm all for it in filtering some junk out of vhs and have even tried my own filters development for such, but when I really want the maximum, I want to keep most of everything as is to a finished product.

So, I am here asking for any tips and suggestions to help me get closer achieving this through x265.

[KarMa]

I just want to retain as much of the grain as possible because (as KarMa pointed out) the video mostly shows a "smeared" look in those areas with/without --tune grain.

Not sure if I messed up something I wrote, or gave the wrong impression but I see a difference in grain retention between default and --tune grain. With --tune grain doing what its name implies, but at higher CRFs it also has interesting HEVC artifacts which you don't always see with the default (no --tune grain), as the default tuning smears it out I guess.