Hey, FYI - I’ve found a workaround by using Proteus 2x, then another pass with proteus 2x to get rid of the black splotches/blobs
If you’re getting the blobs, try multiple passes with different AI models>
In the past, there have been posts about the phenomenon occurring not only in 4x but also in 2x.
I do not believe that it does not occur at 2x, just that the probability of it occurring is low.
If the cause of the occurrence was known in the first place, I would think that 4x could be corrected, but as long as that has not been done, the fact that the cause remains unknown has not changed.
Topaz once attributed this phenomenon to thermal runaway of the GPU, but testers’ tests have proven that there is no causal link to thermal runaway. And since then, there has been no action from Topaz 
1 Like
Ive had the same issue when upscaling 1080 to 4k with the proteus model but it varies per instance. When I reset the program, it sometimes goes away. But will occur in other areas. Not sure why… Has there been an update to this? Im using the latest version.
A bit late to (revisit) the party, but has this finally been resolved for v3 yet? It only occurs for me when upscaling, say, 1920x800p to 4k, and then with ‘crop to fill.’ Especially since the latter takes ages. If not, then it’s high time this bug be squashed! (at 5.4 now).
1 Like
They can’t fix a faulty model, the only solution is to develop a new model.
I know; but I don’t believe this is a model issue. Rather, I strongly suspect this is a memory issue, stemming from Topaz’ hopeless flawed way of cropping. First they scale, say, a 1920x800p movie to 2592x1080, and only then they crop (or worse, they upscale to 5184x2160 first, then crop). Using such ridiculous huge frames makes some memory areas overflow, I suspect (maybe on your video card even); not to mention takes nearly 2.54x longer than processing the original.
I have brought this up so many times, I’ve pretty much given up; any programmer worth his salt, understands how to do this properly; aka, first crop 248px from both left and right side, and only then scale up the resultant 1424x800 to 3840x2160. Child’s play. But it requires someone to listen on the other side /minirant
1 Like
Whooooa!
Is this real? Can’t be. Topaz, and some users, claim that Proteus is the go-to general model. How long was your process time, resolution and parameter settings?
Oh, it be real. My parameters are in the exact post I made above: Proteus 3 black splotche blotting - #73 by meimeiriver
And the issue only occurs with ‘Crop to fill’ (source was getting cropped to 1920x816p).
Oops, I did missed that, meimeiriver.
Wow! Sorry for your valuable time seems wasted, meimeiriver, but I promise, all is not lost because it did directed me. Thank you.
1 Like
I am fed up. The devs are never going to fix this. Scrutinizing the command line options now, to see whether I can get ffmpeg to pre-crop the source first. Totally absurd I have to do their homework, though; but so be it.
More at 11.
1 Like
Maybe indeed not. 
After carefully examining how cropping is done, I realized cropping a source to 816p does NOT automagically crop the sides off (which it absolutely needs to do, as those sides will inevitably be lost on upscaling to 4k). So, I added an x-value for the pre-crop (see below). These values may not be entirely correct yet, as TVAI seems to use a 4px (overscan?) area I can’t quite place. But the black blotches are gone, and fps has doubled again. 
(See below)
ffmpeg “-hide_banner” “-i” “F:/jobs/repo-00.01.16.497-00.02.09.085.mkv” “-sws_flags” “spline+accurate_rnd+full_chroma_int” “-filter_complex” "crop=w=1920:h=816:x=234:y=132,tvai_up=model=prob-3:scale=0:w=1452:h=816:preblur=0:noise=0.32:details=0:halo=0:blur=0:compression=0.18:estimate=8:blend=0.2:grain=0.01:gsize=2:device=0:vram=1:instances=1,scale=w=3840:h=2160:flags=lanczos:threads=0:force_original_aspect_ratio=increase,crop=3840:2160" “-fflags” “+flush_packets” “-c:v” “prores_ks” “-profile:v” “3” “-vendor” “apl0” “-quant_mat” “hq” “-bits_per_mb” “1350” “-pix_fmt” “yuv422p10le” “-an” “-map_metadata” “0” “-map_metadata:s:v” “0:s:v” “-movflags” “use_metadata_tags+write_colr” “-bf” “0” “-metadata” “videoai=Enhanced using prob-3; mode: relative to auto; revert compression at 18; recover details at 0; sharpen at 0; reduce noise at 32; dehalo at 0; anti-alias/deblur at 0; focus fix Off; and recover original detail at 20. Changed resolution to 3840x2160” “H:\veai/repo_560787555.mov”
2 Likes
** phew **
Great job, meimeiriver!!!
1 Like
Yeah, the upscaling to way beyond 4k (as the result of pre-cropping off the letterbox), obviously causes memory to overflow somewhere, as I suspected. You can get away with pre-cropping horizontal bars of ca. 20px (1.08x scale of original); beyond that TVAI goes haywire.
Glad at least this one is licked for future projects. 
EDIT: I underestimated the fps increase. It went from a measely 2.2fp to 10!
Which just goes to show to what absurd sizes TVAI must be upscaling the cropped source first (which, by all logic, should ere go faster).
2 Likes
What about if we upscaled in a first pass using another method then fed it back in so no upscaling was required by TVAI? Would that also solve blotching issue?
1 Like
Yes, it assuredly would. Which is what I used to do mounting a VapourSynth, pre-cropping script. See VapourSynth Preprocessing with AVFS
Alas, Topaz killed that functionality. 
Actually, misread you at first. You are talking about pre-upscaling, not pre-cropping. That also works (as long as the original doesn’t exceed 4k). But part of the charm of TVAI is, that a lot of the A.i repair occurs precisely at the upscaling level (more pixels to interpolate?). So, I rather continue letting TVAI do the upscaling, and pre-crop myself when needed.
1 Like
Hello.
Looking at the command line you described, it seems to me that there is no scaling done by AI, only noise reduction.
The ffmpeg filter is listed in “-filter_complex” and I will try to break down the contents.
-filter_complex crop=w=1920:h=816:x=234:y=132,tvai_up=model=prob-3:scale=0:w=1452:h=816:preblur=0:noise=0.32:details=0:halo=0:blur=0:compression=0.18:estimate=8:blend=0.2:grain=0.01:gsize=2:device=0:vram=1:instances=1,scale=w=3840:h=2160:flags=lanczos:threads=0:force_original_aspect_ratio=increase,crop=3840:2160
The filters are chained by “,”.
The TVAI filter is “tvai_up” and the others are FFMPEG built-in filters without AI.
crop=w=1920:h=816:x=234:y=132
This is cropping.
tvai_up=model=prob-3:scale=0:w=1452:h=816:preblur=0:noise=0.32:details=0:halo=0:blur=0:compression=0.18:estimate=8:blend=0.2:grain=0.01:gsize=2:device=0:vram=1:instances=1
This is the AI filter of TVAI. Scale” can be set to 0, 1, 2, or 4.
If you set “1”, “2”, or “4”, you can set the magnification factor to be enlarged arbitrarily.
If 0 is selected, the image size is compared to the input image size using w and h, and either 1, 2, or 4 is selected.
In this example, the image is cropped from 1920x1080, 1920x816 is input, and 1452x816 is specified as the output size, so 1 is assumed to be set internally.
Also, since “noise,” “compression,” and “estimate” are specified, noise reduction and compression artifact removal are applied, and automatic settings are made by reading in 8 frames.
scale=w=3840:h=2160:flags=lanczos:threads=0:force_original_aspect_ratio=increase
The image is enlarged to 3840x2160, but this is due to FFMPEG’s built-in filter, which does not use AI.
The aspect ratio of the original is taken into account in the enlargement.
crop=3840:2160
This is cropped to 3840x2160.
3 Likes
Thank you for your reply!
That… surprises me, tbh. I would have thought doing upscaling by the A.i. greatly benefits the process.
The image is enlarged to 3840x2160, but this is due to FFMPEG’s built-in filter, which does not use AI. The aspect ratio of the original is taken into account in the enlargement.
Indeed, looks to be just a regular Lanczos resize. In the end, it doesn’t matter much, as, after the upscaling, the A.i still has more pixels to work with.
Apart from messing with the x- value (and setting pre-crop value for x to 1452 (1920 - 2x234 for sidecrop), this is the original command line set by TVAI.
-filter_complex crop=w=1920:h=816:x=234:y=132,tvai_up=model=prob-3:scale=0:w=1452:h=816
The way I constructed this (from looking at several examples in my tests, created by GUI), was to interpret that TVA uses 2 different syntaxes to crop to the same result; first one essentially says “Crop to 1920x816 by substracting an x value of 234 off each side, and an y value of 132 to be taken off of top and bottom.” The subsequent one pretty much does the same thing, but simply uses the resultant values directly (aka, 1452x816). Not sure why it uses these 2 different syntaxes, but appears to work when I do it that way.
