You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Follow-up to #14737: drop output_type="latent" from modular decode blocks #15071
#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.
Activity
dhvani7014 commentedon Oct 18, 2026
Hi @yiyixuxu, I'd like to work on this. Should I wait for #14737 to merge first, and leave ltx2 for #14612?
yiyixuxu commentedon Oct 18, 2026
@dhvani7014 sounds good!
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