Optimized Apollo Variant for 3x Interpolation (9-Step Internal Model) and 24 to 60 fps

Topaz Video Ideas
1

The Problem:
Currently, when using Apollo for 3x slow motion or frame rate conversion (e.g., 30 fps to 90 fps for VR glasses), there is a noticeable judder.

My analysis shows this is due to the fixed 8-step internal architecture of Apollo. When forcing a 3x stretch, the software has to distribute 8 internal steps into a 3-frame output, leading to an inconsistent sequence (e.g., two large movement steps followed by one smaller step).

While Aion (16-step) masks this better, but it comes with a 50% performance penalty (3.8 fps vs 7.6 fps on an RTX 5080 in 4K).

The Idea:
Introduce a ā€œRefined Apolloā€ or a specialized mode that utilizes a 9-step internal generation
(or a flexible step count).

A 9-step model would allow for perfectly homogeneous 3x interpolation (3+3+3), eliminating judder entirely while maintaining the high efficiency and speed that Apollo is known for.
This is especially crucial for VR users, where consistent frame pacing is mandatory to prevent motion sickness.

(Note: MeganeX superlight 8K , with its 90Hz max refresh rate)

Performance Comparison 3x slow motion or fps conversion (4K on RTX 5080):

  • Chronos: 6.2 fps (High artifacts in fast motion)
  • Apollo: 7.6 fps (Great speed, but significant judder at 3x)
  • Aion: 3.8 fps (Good pacing, but 2x slower rendering time)

Conclusion:
3x stretching is a ā€œsweet spotā€ for many creatorsā€”it provides significant slow motion without losing too much energy. Having an Apollo variant optimized for factors of 3 ( 9x step internal) would bridge the gap between Chronosā€™ speed and Aionā€™s precision without the massive render-time hit.

I am looking for the ā€˜Golden Ratioā€™ between Apolloā€™s speed and Aionā€™s quality.
A 9-step internal model would be the perfect solution for 3x interpolation: It provides enough temporal resolution to avoid the morphing artifacts of Chronos, while being significantly faster than Aion by avoiding the overhead of 16-step calculations. Itā€™s the most efficient way to get professional-grade 90fps VR content.

Best regards,
seifenchef

2

I think this is a good idea. Are you not able to vote for it yourself?

3

I do not understand you. I am not a native english speaker.

4

There is a ā€œvoteā€ button at the top of this page. You can press it to cast a vote for your idea.

5

For normal videos Iā€™ve been doing 2.5x to go from ~24fps to ~60. I am curious if you know if that makes the same judder as 3x?
All I know is that when I watch the the videos, I get very distracted by how things move. I donā€™t get distracted in the same way while watching videos that are recorded in 60fps.

6
  1. which model do you use?
  2. can you see it in the result?

kind regards

7

I use the Apollo model with ā€œduplicate frames replaceā€ off. I donā€™t know if I can identify judder, I just know that something becomes distracting about the motion after itā€™s done. Itā€™s not throughout, but about every ten minutes I think I see something not move normally.

8

Of course, it is true that JIDDER, especially when it is only ā€˜micro stutteringā€™, is not always noticeable, and above all, not always immediately noticeable.

I think many consumers donā€™t even see it !

I think 24 (or 23,98) to 60 is a very difficult field.
To be honest, I donā€™t know how Topaz does it.

AI says:
______________________________________________
" In Topaz Video AI the Apollo model uses a specific mathematical approach to handle non-integer frame rate conversions, such as the 2.5x jump from 24 fps to 60 fps.

How Apollo Handles the 2.5x Factor

  • 8-Frame Grid: Apollo works by generating an internal ā€œgridā€ of 8 possible interpolated frames between two original frames (creating steps at 0.125, 0.250, 0.375, etc.).
  • The ā€œNearest Matchā€ Logic: To reach 60 fps, the software needs a new frame every 0.4 intervals (1 / 2.5). Since 0.4 does not perfectly align with Apolloā€™s 0.125 increments, it selects the mathematically closest generated frame from its 8-frame pool to fill the timeline.
  • Replacing Originals: Because 24 and 60 donā€™t sync up perfectly every step, Topaz often discards the original frames entirely and replaces them with AI-generated versions that fit the new 60 fps timing more evenly.

Potential Issues with the 2.5x Factor

  • Micro-Stutter (Judder): Because the 60 fps timing is ā€œroundedā€ to the nearest of the 8 available Apollo slots, you might notice slight inconsistencies in motion (pacing issues) where some frames feel a millisecond ā€œoffā€.
  • Sharpness Loss: Since the original 24 fps frames are often replaced by ā€œbest-fitā€ AI frames to keep the motion smooth, the video may lose some of its native clarity.
  • Apollo vs. Chronos: For ā€œnon-doubleā€ conversions like 24 to 60, Chronos or Apollo Fast are often recommended over the standard Apollo. Chronos is more flexible with non-integer multipliers, while Apollo is optimized for exact 2x, 4x, or 8x factors.

If you experience ā€œjitteryā€ pans with Apollo at 60 fps, try Chronos Fast. It handles the math of a 2.5x conversion more linearly and often avoids the ā€œstrobeā€ effect that can happen when Apollo rounds frames to its 8-step grid. "
______________________________________________________

ā†’ You can certainly try AION; the steps are finer, 16 instead of only 8, errors are halved, but you need twice the rendering timeā€¦ the same issue I described in the initial postā€¦

kind regards

1 Like
9

Check out this topic. I do think the combination of Apollo + Chronos is better than just Apollo.
Maybe the tests I have done with Aion were not long enough. To me, the results were the same as Apollo but with static grain added to all the motion. I should test it again. The longest movie I did with it was probably only two minutes long.

10

I am increasingly convinced that we need several Apollo variants, not just the 2x, 4x, or 8x optimized versions we have now.

So first, one of 9 possible interpolated frames between two original frames for three-times fps conversions or three-times SloMo.

And then a special variant for 2.5 from 24 to 60 fps ?

Mathematically, this would simply mean that Apollo takes 10 stepsā€”but over 2 images!ā€”and takes every second one.
Result: 5 images in the time where there were previously 2ā€”perfect judder-free conversion.

Unfortunately, this would mean discarding every other original image.
Only Topaz can answer whether this is good for the quality.

ā†’ Iā€™m afraid it would probably be faster and better to go from 24 to 72 fps ā€“ but to do that, we would first need a optimized version of Apollo for this ā€¦

11

" I do think the combination of Apollo + Chronos is better than just Apollo."

For what reason?
Apollo always has the problem of being optimized for 2;4 or 8ā€¦

But Chronos alone may be not have the Judder-Problem.
ā€¦ but I think to much artifacts - to my liking ā€¦

ā€œtests I have done with Aion were not long enough. To me, the results were the same as Apollo but with static grain added to all the motion ā€¦ā€

ā€¦ ? ā€¦ I hadnā€™t noticed that yetā€¦ only the long render-time is my problem ā€¦

ā€¦ I once had a scene where a large radiator with a rotating rotor slowly moved across half the screen.
AION was the only model that could do this in 2x slow motion without artifacts ā€¦ all the other models chopped up the moving rotor blades ā€¦ :slight_smile:
.

12

Apollo at 2X and Chronos at 1.25X. Since Apollo does the main interpolating, it produces clearer frames for Chronos to work with and so Chronos produces less artifacts than normal.

The reason I think the combination is better is from processing two episodes of a show with Apollo at 2.25X and two more with Apollo + Chronos. The two with only Apollo were distracting when I watched them. Something about the motion seemed wrong quite often. The other two, I mostly forgot that they had been interpolated. There was still artifacts, but they were less distracting.

13

Okay, that could make sense.
But what does your workflow look like?
You canā€™t do both steps at the same time, so is it double the work?
The factor 1.25 isnā€™t selectable anywhere, so Iā€™m guessing you go from 24 to 30 fps with Chronos and then to 60 with Apollo?

I think that, in addition to a mathematically perfect 3x slow motion, which I love and which is needed for glasses like Meganex (30 to 90 fps), a conversion from 24 to 60 fps is definitely something that many people are interested in.

There should be a mathematically perfect workaround for this as well.

kind regards

14

Yes I do it in two steps. I have not timed if it takes longer than Aion, but it is more than double the time to process than just Apollo doing 2.25x.
Apollo 2x must be done first because Chronos blurs random things.
You can type in 1.25 in the Slow Motion entry box and it uses it.
For simplicity in getting the correct frame rate in the final video, I output to images for all the steps then use ffmpeg to make the final video at the correct new frame rate.

1 Like
15

Yes, I think you should compare both approaches.
(Apollo + Chronos versus Aion)
In terms of quality and time.

And let us know how it goes. :slight_smile:

16

" Apollo 2x must be done first because Chronos blurs random things. "

Yes, Chronos is the fastest as long as you only need one intermediate image, but itā€™s also the worstā€¦ with the most artifactsā€¦

The number of ā€˜simultaneously generatedā€™ intermediate images significantly determines the quality of the whole.
(You can probably imagine it like this: it is the number of points from which a curve/function is derived).
That is why Aion (16 steps per step) is better than Apollo (8 steps per step), and both are better than Chronos.

17

I tried to do a full episode, but Aion crashes after a few hours of running on my computer. My other computer probably wonā€™t have it crash but it doesnā€™t have enough drive space to hold the tif images.

18

Damn, AION crashes a lot for me too.
(2K is no problem, 4K sometimes works, sometimes doesnā€™t, 8K doesnā€™t work at allā€¦)
Itā€™s probably very demanding in terms of hardwareā€¦
we need NASA computers :slight_smile:

Hmmm, do you really have to export TIFF?..
thatā€™s horrible! SCNR

Canā€™t you use ProRes?

"[quote=ā€œForSerious, post:14, topic:100359ā€]
For simplicity in getting the correct frame rate in the final video, I output to images for all the steps then use ffmpeg to make the final video at the correct new frame rate.
[/quote]

I donā€™t understand. Why canā€™t you get the desired frame rate from Topaz?..

Have you ever tried Shutter Encoder? Itā€™s incredibly fast because it only rewrites the timestamps, which of course changes the total length accordingly ā€¦
ā€¦ Sometimes it does something to the soundā€”if thereā€™s music, treat it separatelyā€”
I like to use Shutter Encoder for 23.98 ā†’ 24 or 29.97 ā†’ 30, or 23.98 to 20 fps in special cases ā€¦

19

ProRes is not lossless. I could do ffv1, but then I have to fight with the encoder to get the output video at the correct frame rate.
It really is easier to make most video encoders comply if they need to encode a bunch of images.

My main computer has an AMD 9070 XT. I have an Nvidia 4070 ti I could put in it, and I know it wonā€™t crash. Doing that though, is more effort than I want to put into this.

20

Yeah I give up. I used another drive thatā€™s big enough on my other computer. It has a 3080 ti, Iā€™ve never had a problem with it. It crashes within 10 to 30 minutes every time. So then I installed TVAI 5.3.4 and the same thing happens.