Interesting method, and Proteus v2 found values: 33 30 26 1 16 -1, but those do not work on this movie. It results in no visible change in the output. These values I found experimentally with the preview:
55 56 55 12 57 55
However, with those values the MP4 video looks weird: blurry and sharp. Not acceptable. I also tried Proteus v1 with the same values, and there’s no visible change. In all others tests I’ve done, I see no difference between Proteus v1 and 2. Maybe I made an error in the json files? I’m running VEAI v2.3 thus I don’t have Proteus v3.
What has made a difference is to edit the Artemis Dehalo json file, artemis-mqs-1.json. I changed “vidArtifactType”: [“Compression”, “Blurry”] to “vidArtifactType”: [“Compression”, “None”] and the model’s effect is noticeably reduced and it no longer oversharpens and thickens fine features.
I searched the forum and no one has posted about changing these parameters to change the model’s behavior. I opened up all the json files to get an idea of possible parameters. I found removing “Compression” is bad. MPEG compression artifacts then show in the output.
There’s also “vidQuality”, set to “[2]” for the Artemis Dehalo model, and ranges from 0 to 2 for other models. I played with this value and found no change in the preview for the Artemis Dehalo. I’m not sure when VEAI reads the json files, so I closed and reopened VEAI for each test.
I’m guessing “Blurry” tells VEAI to apply extra sharpening, and changing it to “None” skips the extra sharpening, which is what I wanted. I’m also guessing it’s using Warpsharp which can thicken features because that’s thickening is gone now. The MP4 video is currently being created so I’m not sure yet if this is going to work (I output to PNG sequence from VEAI).
I believe json files are coming back in the next version. Can anyone confirm?
Ok, so you say the last one wasn’t great, it’s gone now but something else will happen in the future… what about the people who were happy with it? We just get left in the lurch because of - what, a whim?
So it wasn’t perferct - what is? The program still sometimes crashes on a long clip, or loses track of Frame Rate, or makes half the screen go black; I just reprocess that file it until it gets through it successfully.
Why not remove all of the models that ever crash? !!!
Please. Get the current Audio re-instated, even if only accessible via severe warnings, whatever … but please don’t let functionality used by lots of people just get thrown away.
Bingo! That was it! Changing “Blurry” to “None” gets me the results I wanted. I also tested post sharpening with vsMsharp, but that made it a “blurry sharp” video like I got with Proteus.
Which raises a question- why have the developers added extra sharpening (Warpsharp it seems) as a forced option with most models. Only by hacking a json config file am I able to turn that off. Why is this option hidden there? This should be brought out to the GUI as a configurable option. And folks using newer than VEAI v2.3 are SOL until Topaz brings back json files.
There is no one right way to post sharpen a video. There are such a huge number of ways to sharpen, that it’s futile to pick one, hide it in the program, and hope it works ok. Warpsharp is only useful on a limited number of videos. Standard sharpening (in Virtualdub2), Msharp (aka vsMsharp), and CAS are the ones I tend to use, and their strength can only be determined experimentally. This is best done in an external app post VEAI IMO (I use Virtualdub2 with Avisynth).
Now I know why some folks have been saying VEAI sharpens too much. Most of the models have it turned on! Only Gaia HQ and Chronos have it off. And if they are indeed using Warpsharp, I can only shake my head.
I may mod all my json files to turn off sharpening in all models. I’d much rather do it post VEIA with the most appropriate manner and strength.
“Noise” is one of the other parameters. I didn’t test it much, but I’m guessing it applys extra noise reduction. Again this is an effect that there is no one right way to do it and the effect must be configurable, best done in an external app pre and/or post VEAI IMO.
“Compression” is another. It appears to apply deblocking to reduce MPEG artifacts. The amount of processing should be configurable.
Proteus is a different AI model compared to Artemis Dehalo IMO. Because Proteus is configurable, that might suggest it’s a substitute for other models, which is false. All the models should have configurable parameters via the GUI.
Now would be a good time for a Topaz developer to confirm or deny my observations about sharpening.
Does anyone know if it’s confirmed that this fix will be only included in a major or minor release? This bug was introduced more than 6 weeks ago (and has continued through 2.6.0, 2.6.1 and 2.6.2), so I would expect it to be fixed in a maintenance release.
As Topaz’s pricing policy states, “Maintenance releases and fixes (v2.0.0 > v2.0.1) are always included free for all users, even if you do not have an active Upgrade License. To download a major or minor upgrade (v2.0 > 3.0 or v2.0 > v2.1) an active Upgrade License is required.”
My subscription expires next week, and, if the fixed version is not released by then, I don’t think I should have to pay $99 US to have a bug fixed. I’m willing to forego new features for a while because versions with new features often result in new bugs that require users to use previous versions of VEAI anyway. Therefore, I’d like to see some more stability to the releases before committing to another subscription.
I really hope this fix is introduced in a maintenance release, so I will still be eligible to use it when my subscription expires.
I recently bought VEAI at the Black Friday $99 price, which to me feels like a fair price for the current state of the software.
I saw that 2.6.2 listed timecode as “officially supported” and that it “works correctly in the app.” So I tried VEAI again in the hope it would now finally detect timecode in clips, and pass them through. It doesn’t.
I really don’t get what this “timecode support” is. If it doesn’t read the timecode in the source file, how can you claim it has any timecode support? The in-app timecode mode always shows the file starting at 00:00:00:00. The lack of timecode pass-through to output files is a major issue for me.
Even worse, 2.6.2 is still writing incorrectly formatted output files, with wrong start_time and start_pts values:
start_pts=507
start_time=0.033008
This compounds the issue of not having timecode in the output files, because attempting to use ffmpeg to add timecode to the files written by Topaz always results in a file which is one frame too short. I first reported this back in the 2.4 thread.
There is a workaround, but it took me days of experimentation to find it, and because of this invalid metadata in the Topaz output files it requires multiple steps of ffmpeg processing to add back the timecode I need.
Please work on these issues. They’re making VEAI much less useful for me than it could be
I saw mention in the 2.6 thread that the video processing engine is being rewritten? I do hope this will finally support timecode in output files, and will create output files with correct pts values. It would also be nice to get some more input and output formats; given ffmpeg is used, I find it odd that the choice of input and output formats is so limited. Why no DNxHR output for example? And I thought it was very odd that ProRes 4444 was just removed completely, rather than being fixed. Wasn’t there also an Uncompressed video output option, which is now gone too?
Audio has never worked in VEAI. No, you do not want it unless you want crap quality 2 channel, regardless of what you put into it. Enough said about it. They WILL add audio in a future version when it can do what it’s supposed to.
Hi…I have tried your suggestion, but I don’t know if artemis-mqs-1.json is the json for artemis dehalo v1, because for example some other models have the number of the version on the name of the file. If I open artemis-mqs-1.json, in the file appear version 1. I don’t know if I have to create a new file artemis-mqs-2.json and inside write version 2. I have tried to delete the json’s file for artemis in appdata\roaming etc. and in program files\topaz etc. The software works the same.
Apologies if this is the wrong place to be posting, but I can’t create a new thread in the discussion category.
I am currently trying to deinterlace a video with VEAI using the Dione models (Robust & DV). The video is 1080i 59.94fps. When I use either of the Dione models, the resulting output file is a deinterlaced video that flickers black every few seconds. Would anyone know why this is happening? Here is the MediaInfo for the file. (I’m not sure why the MediaInfo says it’s 29.97fps when it definitely isn’t.)
hi, so i’m working on interlaced videos too, it gives me the same problem, it’s very disturbing. I had found an alternative with a version of veai so that the video came out well, before I knew veai I always deinterlaced my videos with vegas pro (I still do), because it was the best deinterlacing software, and j 've spent sleepless nights testing others like handbreak, virtual dub, I have tried absolutely everything I think, the problem with the gpu deinterlacing of vegas pro is that at times in the video there are artifacts at the video grain level which are hard to remove with veai when you want to keep almost all the details, on the other hand there is no staircase effect with vegas pro, that’s why for me it’s is the best, then maybe for my case and my old hi8 videos in sd, others will prefer other deinterlacing methods like yadiff, eula, etc …
All that to say that the way that I found with a version of veai, is to produce the video (25i) with vegas pro, with the gpu deinterlacing in the properties, leaving the progressive fields and to produce it in avi (pal, yuv or uncompressed) in 25 fps, bottom fields first, deinterlacing each frame. By then passing it in veai, the problem was solved, the problem is that either I find more of the video settings that I made before producing with vegas pro, or it is the version of veai that gives me anyway those black sparkles on the movements.
And if ever a developer reads me, it’s really the dione dv and dione tv part that I would like it to be seen again, because for my part these are family videos that date from 1996 to 2002, very important videos with which I have been working on for 6 years because I am really picky about the quality.
For your case if you want, send me a part of the basic video to see what I can do, because as much with my method, it can work, and I surely found another solution yesterday, from now on I will be more motivated to work on my videos because I just went from a gtx 1660 to an rx 6900 xt, and I’m happy to see how much the processing time has reduced so much!
29.97 is the final frame rate based on a complete frame, both are technically true for interlaced. The publisher of the disc has defined each pass, odd and even, as it’s own frame hence 59.94.
I have yet to see a deinterlacer that tops QTGMC. I tried Dione on several videos and had poor results. I don’t know why the VEAI devs thought a motion compensating deinterlacer could be created with machine learning.
Note with QTGMC if you are planning on feeding it to VEAI (this is mega important), you need QTGMC to do a sloppy deinterlace, leaving noise and detail alone. The reason is because VEAI removes the noise and needs maximum detail to work.
This is from my Lucky Girl upscale post:
QTGMC( Preset=“Slower”, EZKeepGrain=0.01, SourceMatch=3, Lossless=2, Sharpness=1.0, Sbb=0 )
SelectEven()
This is a variation of QTGMC creator -Vit-'s most accurate settings, QTGMC( Preset=“Very Slow”, EZKeepGrain=0.5, SourceMatch=2, Lossless=2, Sharpness=0.1, Sbb=0 ), which does no denoising, only deinterlaces.
I purposely ignored the warning about high sharpness settings in lossless mode, and it worked fine. Why it worked, I don’t know; this was after a month of working on this video, so rules got tossed in favor of crazy experimentation.
You can use a program with a front end / GUI (general user interface), for example StaxRip or Hybrid.
Personally, I prefer StaxRip. You can google the avisynth-wiki and search “QTGMC” - it’s quite detailed and explains what the functionality of QTGMC represents (which are a lot of useful tools and settings), the only drawback is that you have to experiment with the settings a bit and it takes a while to get the hang of it. But once you get more used to actually using strings/commands and numbers to tell the function what to apply, it becomes easier.
In the beginning it took me a bit, but now it has become quite easy for me. I even know most of the functions I need by heart, sometimes I just have to take a look, since I don’t always remember how some settings are defined (in numbers).
That’s the difference between an open Source software with people working on it from all around the world, and thinking “as a programmer” and not as a “user”, and a team like Topaz, where they do software for user and being usuable by most people. I agree that QTGMC provide better result, for the few i used with deinterlacing with VEAI (I use QTGMC), but yes, it’s need a bit of work to understand how it’s work. (and it’s much worst without StarxRip !)
