The bug / behavior
When I perform an image interpolation from a sequence of images and there are some identical images at the beginning, some images are always skipped afterwards, but when I use a video file, the interpolation is correct.
This behavior is observed with all Apollo and Chronos models.
I have also disabled “remove duplicated frames”
EDIT: There seems to be a general problem with image sequences, because it also occurs during upscaling.
BTW:
I have inserted the same frames myself at the beginning, because Apollo8 generally omits the start-frames at the beginning and it might be another bug.
Link to a zip-file with input and output example → rename it at download! (90mb) link
Link to a zip-file with only input example → rename it at download! (1mb) link2
system profile
TVIA v3.3.8
Windows 10 64bit
rtx 3090
I don’t know if this behavior was before v3.3.8, because I usually use video files as input. For me is this issue new and I don’t know if there is a general problem of image sequences as input in the program.
I have now tested several old versions and there seems to be a general problem with image-sequences, as there is also the problem with upscaling.
v3.0.0 has also this bug and video-files do not seem to have this problem.
Btw Apollo seems to have a different problem in the newst version, even with video-files as you can see in this other post: https://community.topazlabs.com/t/first-frame-missing-apollo-model/47808
In version 3.0.0 Apollo had not this problem and it is not direct related to my bug, but as a sideffect you can see the problem from apollo here in my Issue-post too.
Here is a link to a new zip file with test-data where you can quickly see the problems yourself. Link (1mb)
Thx, and to be clear that the thing with Apollo and the thing with image-sequences are two different bugs. Sorry if I was not exact in describing problem and that I have mixed two different bugs.
First frame is always missing when using the Apollo Model. Prior to Topaz Video 3.3.2 both the first and last frame used to be missing. Looks like 3.3.2 has fixed the last frame issue but the first frame is still missing.
Windows 11. Nvidia 3080. Topaz Video 3.3.2.
Your log files (Help > Logging > Get Logs for Support)
Any screenshots as necessary
[Please be sure to have searched for your bug before posting. Duplicate posts will be removed.]
Same here and only Apollo8 has this bug and I think all other models are correct.
Another strange behavior is, that Apollo8 unlike all other models also removes the original frames… Here would be a choice good? maybe “keep original frames”
I made a test video where each frame is numbered and did a x16 slo-mo with Apollo. I can confirm as of v3.3.1 that with “replace duplicate frames” off, the first and last frames are missing. With “replace duplicate frames” on, I presume some duplicate frames were detected, perhaps at the start of the slowed video… but instead of removing these frames, it removes more frames at the end (ie, there is 1 frame missing at the start and several missing at the end).
A workaround could be to set the trim to 1 frame earlier and 1 frame later than what you want in the output, but this isn’t feasible at the start and end of the video so I’m using ffmpeg to add some blank frame end caps.
I’ve updated to v3.4.2 and the problem is rather different now:
The last input frame is no longer being skipped, as long as I remember to disable “replace duplicate frames.”
The first input frame is no longer being skipped, but at least the first output frame is still being skipped. I’ve uploaded what I mean to the dropbox. The input video counts up for each frame from 0 to 59 and I’ve applied Apollo slo-mo x16. The desired output should start on a clear “0” and end on a clear “59.” However, you can see that the first frame is not a clear “0,” but rather the “0” has already started to morph into “1.” The last frame is a clear “59.” Hence, the issue is much better now, so close to being fixed.
The bigger problem is that now I can only trim down to a minimum of 60 frames (for a 60 fps input video), which makes the software no longer fit for my purpose. Previously, I could trim down to any number of frames. Why add in this limitation?? This sounds like a strictly worse change?
For the third issue, the trim limitation has not been altered. There has consistently been a one-second minimum when using trim. If you still have an example from v3.4.1 where you were able to trim less (with the same file), please let me know.
There was no such limitation back in v3.3.1. What is the purpose of adding in a 1-second limitation for the user, since this appears to do nothing other than reduce functionality? Is there some sort of technical issue that wasn’t there before?
