Setting up a new pyramidflow-miniflux (768p) environment in a separate location. [I was able to generate 768p videos locally with 8 GB of GPU VRAM]

Since I unintentionally destroyed my old environment, I created a new, separate ComfyUI environment and
was able to restore the pyramidflow-miniflux (384p) environment there.

During that process, I realized that pyramidflow-miniflux (768p) has a dedicated workflow,
pyramid_flow_miniflux_768_img2vid_example_01.json, and unless I try
pyramid_flow_miniflux_768_bf16.safetensors there, I cannot yet definitively say
that "pyramidflow-miniflux (768p) is impossible in my environment."
I was able to change my perspective on this.

I immediately dropped pyramid_flow_miniflux_768_img2vid_example_01.json into a blank ComfyUI tab,
and the workflow appeared without any missing node alerts.
In terms of the environment, it might be the same as pyramidflow-miniflux (384p).

I re-specified the required resources in each node to point to the actual files and ran it.
The process ended with an OOM error near the end (Pyramid VAE Decode).
(I was too discouraged to take a screenshot)

Since the generated data must be larger, I reduced the video length in the preceding
PyramidFlow Sampler by half (from 16 to 8),
reducing it from 6 seconds to 3 seconds.

A video with a long side of 1280 pixels (768p) was successfully generated.
It is not the glittering screen I had before.

However, it is unsettling. No matter how I adjusted the Guidance_scale or Video_guidance_scale,
I could not avoid the deformation caused by incorrect interpolation during upward camera movement.

I tried inputting a portrait-oriented original image where information loss is less likely to occur at the top,
and swapped the width and height specifications...

Oh. The strange upward camera movement disappeared, and I was able to avoid the unsettling deformation.

I am happy to retract the statement that "pyramidflow-miniflux (768p) is impossible
in my RTX 4060 (8 GB GPU VRAM) environment."
At the same time, there is no longer a need to purchase paid credits on Tensol.Art
to seek the true potential of pyramidflow-miniflux (768p).

It had been a mystery why only the 768p video version wouldn't work when the CheckPoint file size
hardly changed, but the truth seems to be that the generated video data was too large,
and the process could not be maintained until the end.

Even though it is called a dedicated workflow, the only difference from the
pyramid_flow_miniflux_img2vid_example_01.json for pyramidflow-miniflux (384p)
seems to be the difference in the magnification ratio specified by these width and height settings.

I don't see a difference in video generation quality, but perhaps for this magnification ratio,
if I don't use this dedicated flow, pyramid_flow_miniflux_768_img2vid_example_01.json,
the tile processing in Pyramid VAE Decode might not work correctly, resulting in a glittering screen.
(I had the impression for a while that it might be a tile processing issue, and that intuition seems to have been correct.)

This was also the true nature of the mystery when I couldn't avoid the glittering screen with any settings
before (before destroying the environment): "The mystery was that I had tested it many times by changing parameters,
but the automatic saving of the output image only succeeded once."
In short, the output I tried to generate was too large to complete the save.

Now, the question is how much I can extend the generation time under OOM countermeasures,
or, like in my past HunyuanVideo environment setup, try halving values like tile_sample_min_size
in the Pyramid VAE Decode node...

The i2v video generation logic for the 384p and 768p versions seems to be exactly the same,
and the performance comparisons with other generation tools using pyramidflow-miniflux (384p)
from the past seem to remain valid.
For the first time, I can definitively say that the view that "the comparison is unfair; the true potential of the 768p version of pyramidflow-miniflux is not this low" is unnecessary.

Also, as mentioned above, if the 768p version is a wild horse and difficult to control,
I can output with the 384p version, where I am used to parameter adjustment and the generation time is longer,
and if necessary, output at 1280 pixels on the long side using Dain-APP, just like with Pinokio - CogStudio.
I was able to definitively say this for the first time through this trial.

If I hadn't had the accident of unintentionally destroying my entire environment, I wouldn't have reached this conclusion.
It is truly a "blessing in disguise."

Next, I will try pyramid_flow_miniflux_text2vid_example_01.json, which supports t2v.

Thank you for reading.

(Written on 2025/02/02)