There is a huge error. For some reason, after exporting for a whole day until it was completed, the resulting file could not be played. I look at the resulting file’s information details, there are no details at all, all fields are empty, only the gigabyte size is correct.
Too much waste of time, damage to computers, waste of electricity.
ngl that upscale looks terrible, it looks like a 3d blender render, the ground in the back seems cartoony and flat, the whole image just looks cartoony, im sure if I were to playback the video I would see some motion compesation artifacts at the edges
I have worked with topaz video ai so much I can see the artifacts so clear and im kinda frustrated they aint fixing more artifacts like halo sharpended lines, the motion artifact they called “walking ants artifact”, the appearing background patterns, and detail not being consistent and just warping away into thin air, this Rhea model is a bit more consistent than the other models, I think its the most consistent yet
This kind of depends on what the source is and what your converting it into. The majority of episodes I have looked at are 29.97 with a straight de-telecine to 23.976. I made sure to order and retain the original NTSC episodes so I am trying to not play with the PAL conversions which then have the audio issues with it.
So for me, it is a relatively straightforward process to recover the original 23.976 framerate and I just encode it at that. The time index still lines up, the audio simply gets added back to it at the end. For me, when I re-encode the mage sequence, I do it without audio in Adobe Premiere, then on the extracted file use Avidemux and simply save the audio back in - it generally works without a hitch on 98% of the cases.
There are some episodes where the CGI actually are 29.97 - and I hate those episodes. For example I did 5x seasons of Voyager and the only episode with this issue is the first one, Caretaker. Which as it is a double episode, combined with my method to convert it to 59.94 means I quadruple the amount of frames - but the end result is the same, I can just import the audio back in when done, and I don’t have the judder.
For the usual episodes, I ended up using this export in Avisynth. The commendted out sections are experiments, but with the newer models in TVAI, usually the closest to original I get the better.
D2VSource("D:\Video\DS9\Season 1\Disk 3\Episode 10\VTS_02_1.d2v")ConvertToYV12()
checkmate(tthr2=0)
#ChubbyRain2()
Bifrost(interlaced=true)
AnimeIVTC(mode = 1)
santiag(strv=0, nns=4, nsize=5)
#MCTemporalDenoise(settings = "medium")
#f3kdb( y=48, cb=48, cr=48, grainy=48, grainc=48 )
#aSharp()
Spline64Resize(720, 540)
Crop(10, 10, -10, -10)
Spline64Resize(720, 540)
Prefetch(4)
As the basis for the export. This extracts around 64k frames, then upscale, then encode in Adobe using 23.976.
The Caretaker episode and ones where it it irritating, end up using a modified code from a discussion on this topic (how to convert the original without losing too much detail to 59.94) on one of the video forums:
SetFilterMTMode("DEFAULT_MT_MODE", 3)
D2VSource("D:\Video\NTSC Season 1\Disk 1\Episode 1\VTS_03_1.d2v")ConvertToYV12()
A=Tfm(field=1,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
B=Tfm(field=0,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
C=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=A,d2v="D:\Video\NTSC Season 1\Disk 1\Episode 1\VTS_03_1.d2v",flags=1,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=B,d2v="D:\Video\NTSC Season 1\Disk 1\Episode 1\VTS_03_1.d2v",flags=1,micmatching=0)
interleave(C,D)
Spline64Resize(720, 540)
Crop(10, 10, -10, -10)
Spline64Resize(720, 540)
Prefetch(4)
This produces 330k frames - so that one is always a joy to upscale…
Just lost result of 7 hour render which could have easily been avoided.
At the end of rendering Topaz starts to merge the one or more files into 1 final file.
The size of that result is an easy calculation.
There was no space for that file.
Instead of pausing and telling me to free up space, Topaz goes ahead until it runs (predictably) out of space and deletes BOTH the result and the “workfile”
Now I have to render it all over again.
Please, please check disk space before starting a process which it could know is impossible to complete and remove all work done so far!!!
BTW:
Because finalizing a preview suddenly takes ages before finalizing if the source file is big (40 GB) and is on a classic drive I was forced to place the source files on my SSD, which is of course not a 16 TB disk.
In Windows hat file is located in:
C:\ProgramData\Topaz Labs LLC\Topaz Video AI\models
It solves my problem with having a too big of a result with “medium”
I changed
"cqpValues": { "High": [ 18 ], "Mid": [ 25 ], "Low": [ 28 ] },
into
"cqpValues": { "High": [ 25 ], "Mid": [ 27], "Low": [ 28 ] },
But that is just my preference.
It would still be better if we have at least 6 choices or a possibility to give a custom value at runtime.
It would also help if Topaz shows what values the “low, medium and high” represent at runtime.
I also would prefer this change in the CBR-scale:
…8, 12, 16, 24…
…8, 10, 12, 16, 18, 24…
Is this comedy central?
I thought you were describing the Rhea model.
I prefer Iris and tried Rhea a few times…
During preview it looks very promising, but after watching the final results they all looked as if the actors were in a 3D-game. Clearly artificial.
To prevent Topaz from losing the “work-file” I’m now creating a hardlink of the file.
It doesn’t take any extra space on the harddisk.
When Topaz removes the work-file, you will still have the hard-link.
This piece of software makes hardlinks on windows a breeze:
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html
If you don’t have anything of value to add, please restrain yourself and leave my posts as is.
Where can I apply for a refund?
He was actually (nicely) offering to process the video for you, to save you some time on your failed export…not sure why you thought that was being a ‘smart-ass’…
@tony.topazlabs @kyle.topazlabs Playlist of Youtube Videos Done With Video AI 5 https://www.youtube.com/playlist?list=PLQZ_JUxj249JkYeMVf43Zq6e70lphADVr
I’m giving feedback about an avoidable crash of the program. It is obvious I’m not helped by someone else processing that video for me. It should have been clear to anyone I can do it myself.
I’m helped by a fix of the program and not by someone offering “his service” which would in most cases if not all be “more work”, “more time” and then there’s the fact that he doesn’t know what I’m processing, which is none of his business.
It is impossible he would be saving me time on a failed export.
I would recommend reaching out to the support team directly at help@topazlabs.com this way they can review the logs to see what the error is and how it can be resolved or process your refund if that is the route you would like to go.
AFAIK is what I’m describing expected behaviour of the current implementation of the program.
After rendering and having all the workfiles in place, Topaz starts to create a new file on the target drive.
The exact size of that file is fully predictable as it is the size of all workfiles put together and a bit more.
IMHO Topaz shouldn’t go ahead with this process before it checks if there is still room on that drive.
It did.
When it can see that it’s impossible to create this new file, it should pause and warn me to tell me that I need to free up space.
Topaz Video doesn’t.
It runs into the full disk and removes the target file (understandably), but it also removes the workfile in which all the processing power and time went. The latter was completely unnecessary.
IMHO the programmers just didn’t write code to check if the target drives has enough room to hold the target.
Unless the programmers DID write code to try and prevent it, those logs could be useful to find out how it failed.
So did they write code to check the free space of the drive before creating the final file or didn’t they?
BTW…
All software has bugs and although I didn’t like this, I have no problem with it.
I’m merely having a problem how my report is handled and it isn’t hopeful.
You could have confirmed (or deny) this situation can happen and tell me you’re passing it to the developers so they write a bit of additional code to prevent it from happening in future releases.
It was all I want. I like what Topaz Video is doing and it’s close to a wonder sometimes. It makes it extra annoying to have these forgetful quirks around it which make it hard to work with.
It’s not only this, there are many more things I would like to see improved, but I’m not going to make a list.
One issue at a time.
Probably better, but it’s quite normal to report bugs publicly.
BTW… If you were really sincere about doing a render, I apologise for my reaction.
Still, I think others should have known that it was obvious that I was after a fix of the program.
Your smiley didn’t help. ![]()
Reporting bugs in the release build forum tends to be hit-or-miss. Did you post it in the bugs forum, or to the support email?
Can you provide links?
Click on the Topaz logo (black square at the top left of this page) for the forum home page for all the forums. Each product has its own “Bugs and Issues” forum.
The support email is help@topazlabs.com
