Flux2 pipelines: expose the hardcoded 1MP condition-image downscale threshold (max_area)

[sqhuang]

What does this PR do?

Exposes the condition/reference image area threshold in the FLUX.2 pipelines as a public max_area argument, instead of hardcoding 1024 * 1024.

Currently Flux2Pipeline, Flux2KleinPipeline and Flux2KleinKVPipeline silently downscale any condition/reference image larger than ~1MP before conditioning (e.g. if image_width * image_height > 1024 * 1024 in pipeline_flux2_klein.py). There is no public way to keep higher-resolution conditioning — the only workaround today is patching the private image_processor._resize_to_target_area.

Fixes the inability to override the reference-image resolution cap without touching private image-processor internals. Useful for users who want to condition on higher-resolution references.

Simple change, i think no-issue-needed :).

Changes

• Add a max_area: int = 1024**2 argument to call on Flux2Pipeline, Flux2KleinPipeline and Flux2KleinKVPipeline, and use it in place of the hardcoded 1024 * 1024 threshold.
• Mirrors the existing max_area parameter of FluxKontextPipeline for API consistency.
• Default value is unchanged, so existing behavior is fully preserved (fully backward compatible).

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline (https://github.com/huggingface/diffusers/blob/main/CONTRIBUTING.md)?
• Did you read our philosophy doc (https://github.com/huggingface/diffusers/blob/main/PHILOSOPHY.md) (important for complex PRs)?
• Was this discussed/approved via a GitHub issue or the forum (https://discuss.huggingface.co/c/discussion-related-to-httpsgithubcomhuggingfacediffusers/63)?
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests? (tests/pipelines/flux2 passes.)

Who can review?

@yiyixuxu @sayakpaul @DN6 @dg845 @asomoza — Small, backward-compatible API addition to the FLUX.2 pipelines exposing the existing max_area behavior as a public argument.

[github-actions]

Hi @sqhuang, thanks for the PR! It does not appear to link an issue it fixes. If this PR addresses an existing issue, please add a closing keyword (e.g. Fixes #1234) to the PR description so the issue is linked. See the contribution guide for more details. If this PR intentionally does not fix a tracked issue, a maintainer can add the no-issue-needed label to silence this reminder.

[rootamigo]

I need that, thanks

[sqhuang]

Hi @sqhuang, thanks for the PR! It does not appear to link an issue it fixes. If this PR addresses an existing issue, please add a closing keyword (e.g. Fixes #1234) to the PR description so the issue is linked. See the contribution guide for more details. If this PR intentionally does not fix a tracked issue, a maintainer can add the no-issue-needed label to silence this reminder.

Thanks Robot! :) for the reminder! This PR does not correspond to an existing issue, so there isn't an issue to link with a closing keyword. Would a maintainer mind adding the no-issue-needed label to suppress this check?
And Also, whenever you guys have a chance, I'd really appreciate a review.
Thanks!

@yiyixuxu @sayakpaul @DN6 @dg845 @asomoza