It appears that now that we have a released version of VEAI 3.0, there is a (new) problem with export.
On selecting Export, it opens the source directory for the file being processed. However if the destination folder is changed, VEAI uses the Source folder to build the temp file and assigns it a temporary-style name, like “428246860_tvai.mov,” not the name that was keyed into the filename line of the “Export As” file dialog.
If a lossless format has been selected, the temporary output file can be huge, which can cause problems, especially if the finished ‘temp’ image is then to be copied to its final (intended) name, I could easily overfill the drive and terminate. - I believe that this has already happened here several time this last few days.
The temp files should be built (and deleted) from the temporary file area designated for VEAI to use. This should be either the default temp or. the temp folder specifically set in preferences.
As a final suggestion, I, believe that VEAI should create it’s own sub-folder in the temp area. - For the last few weeks of beta testing I’ve allowed it to use the default temp area. I inspected it today an found that there was nearly 300 GB of temp .AVI, .MOV and .TIFF files from previous VEAI runs there, which I had to delete manually. Some of them were quite recent. - A real waste of space.
This is during the Export processing. Even though it is almost done processing now, it still shows the opening frame (Paramount stars). I thought moving the slider (1) would somehow make it show the latest processed frame (VEAI does this automatically).
Interesting observation regarding CPU/GPU usage in Windows…
I run a i9-12900 CPU with a RTX-380Ti. In version 2.6 Topaz VEAI ran exclusively on the Performance core if it was open on the desktop, but exclusively on the Efficiency cores if minimized. Version 3,0 runs on both when open or minimized.
Also in 3.0, the average load on my CPU is ~15% vs ~50% on the GPU. This is almost the exact opposite of version 2.6. (This when running two SD>4K upscales simultaneously).
In your example, the ‘prob-3’ file is the one generated during the upscale, while the ‘tvai’ file is just a renamed copy. Check the creation/modified dates on the files. The tvai files will have almost the same datetime stamps for both (depending on you storage media and file size anywhere from seconds to over a minute difference). The model named file will have a last modified time that is later than creation by the time taken to do the processing.
I’m assuming they are doing this to release any over allocation of disk space done during processing. They just forget to delete the original file (as they do elsewhere).
yes, 3.0 is a bit chaotic for some… a new update will normally i think be released tomorrow, i hope with as much of bug fixes as possible.
for Export, if you used Proteus / auto , it shows a picture after some times, usually after 1/3 of the video already processed, more or less. there are unfortunaly some features not implanted yet.
i just had a graphic card update today with a RTX, so i’ll be able to test all this a bit more seriously than before. are you on windows or mac/OSx ?
@ida.topazlabs Suggestion:We should have a list of the various root file names and folder names VEAI has used in the temp file area. Even though it now claims to delete them on exit, there are still a lot of them left from previous test versions. Also, if the app crashes, rather than exiting normally, it leaves a lot of temporary files hanging.
A short time ago I removed about 350 GB of very old VEAI temp files from the temp area. Amazingly, since then I’ve found almost 200 GB more. In other words, there is a lot of space in the temp folders that will remain permanently ‘wasted’ unless the get deleted manually. To do that, we should know what to look for. If someone could provide a list it would be greatly appreciated.
James,
This is already a known issue. (And, incidentally, a fifteen minute difference is actually a little closer than most people get. ) - It will most likely be fixed very soon.
geforce experience can be used for many other stuff than gaming. not need for most of us here, but there are automatic optimisation for some topazlabs product (like put the Vram at the right amount etc…).
there is as well a great screen capture video fonction, using Alt + Z. you’ll not have to download nvidia driver on nvidia website, you can do it with this app. etc … and some other stuff. but just don’t let it running in the background as it can use some % cpu/gpu unless you need it.
Rough and ready slomo speed comparison 2.6.4 vs 3.0.0. Ryzen 7 5800x 8 core/16 thread, RTX 3060ti, 32GB system RAM. Same files used for each, 720x576 progressive at 25 fps.
v2.6.4 on 2x slomo chronos fast is 0.03s/frame. GPU load ~55%, CPU ~70%.
v3.0 SETTING, AI PROCESSOR: GPU (default)
On 2x slomo chronos fast v 3.0.0 is 0.06s/frame. GPU load ~75%, CPU ~10%
On 2x slomo Apollo v 3.0.0 is 0.21s/frame. GPU load ~65%, CPU ~8%.
v3.0 SETTING, AI PROCESSOR: AUTO
On 2x slomo chronos fast v 3.0.0 is 0.03s/frame. GPU load ~62%, CPU ~14%
On 2x slomo Apollo v 3.0.0 is 0.10s/frame. GPU load ~55%, CPU ~14%.
v3.0 SETTING, AI PROCESSOR: CPU
On 2x slomo chronos fast v 3.0.0 is 1.27s/frame. GPU load 0%, CPU ~32%
On 2x slomo Apollo v 3.0.0 is 3.59s/frame. GPU load ~0%, CPU ~32%.
So on AUTO AI, 3.0 chronos fast is the same speed as 2.6.4 chronos fast. Apollo in 3.0 is about 30% the speed of chronos fast in 2.6.4. The GPU-only and CPU-only settings are slow and very slow, I won’t be using them again.
Bottom line is that 3.0.0 is not using the available CPU cores effectively, half of my CPU’s 16 logical processors are not used at all.
But Apollo is a vast improvement in quality over Chronos in video that Chronos could not handle - video with static logos over a moving background for example. It seems to me that for slomo at least, Topaz should concentrate on making better use of all that spare CPU capacity.
I really wanted to like 3.0 and while I think eventually it’ll be an upgrade to 2.6.4 as of now I had to switch back to earlier version.
For starters previews are so much worse in 3.0. Like they actually look worse than if I open the same video in 2.6.4. Why? And they have a host of issues others have pointed out like getting out of sync with the original video.
2.6.4 handled videos that didn’t have square pixels just fine. But in 3.0 they take 4 times longer to process! Why?
When I output a video to ProRes 422 using the Auto Proteus model it generates 2 video files–one will be corrupt and won’t work, and the other will be missing the audio. This happens nearly ever time!
Speaking of Proteus that’s the real deal breaker for me as you can only use the Proteus 3 model in 3.0. On certain videos that model produces annoying flicker artifacts on every other frame. In 2.6.4 I could at least use the Proteus 2 model but with 3.0–no dice.
I don’t know why Topaz was so eager to rush this out the door because it really needs a couple more months of beta testing in its current state.
) - It will most likely be fixed very soon.