Skip to content

Follow-up to #14737: drop output_type="latent" from modular decode blocks #15071

Open

Description

@yiyixuxu

#14737 standardizes the latents the core denoise group leaves in the state: always unpacked and still normalized, mirroring what the VAE encoder blocks produce, pinned by test_latents_output_in_canonical_form. In modular pipelines that already gives users latents for free. Skip the decode block and latents stays in the state, or call pipe(..., output="latents").

Several decode blocks still accept output_type="latent", copied from the standard pipelines. Keeping that path alongside the standard form is redundant and a source of inconsistency: it is a second, separate piece of code that decides what "latent output" means, and it does not have to agree with what the denoise group produces. Today it does not:

family file returns
flux flux/decoders.py packed [B, S, C], still normalized, as images
sd3 stable_diffusion_3/decoders.py normalized latents as images
sdxl stable_diffusion_xl/decoders.py normalized latents as images
cosmos cosmos/decoders.py normalized 5D latents as videos, and skips the safety checker
echo echo/decoders.py denormalized latents as videos / audio
ltx2 ltx2/decoders.py unpacked and denormalized latents as videos / audio

Same argument, different tensors, written into an output slot typed as images or videos. And every time the denoise group changes, as it does for flux in #14737, this branch has to be revisited too. That is maintenance burden and complexity for no benefit.

Proposal: remove the output_type == "latent" branches and keep output_type to pil / np / pt, as the template already documents. The latents in the state are the one latent output. The ltx2 branches can go with #14612.

Related: #14730, #14737.


This issue was written by Claude Code (Claude Fable 5.1) and posted on behalf of @yiyixuxu, who reviewed and approved the text.

Activity

  1. dhvani7014 commented on Oct 18, 2026

    @dhvani7014

    Hi @yiyixuxu, I'd like to work on this. Should I wait for #14737 to merge first, and leave ltx2 for #14612?

  2. yiyixuxu commented on Oct 18, 2026

    @yiyixuxu
    CollaboratorAuthor

    @dhvani7014 sounds good!

    Should I wait for #14737 to merge first, and leave ltx2 for #14612?

    you don't have to wait for these 2 PRs, #14737 most likely will get merged first so as long as you're ok to rebase

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions