- Add warn_if_inverted_colors_likely() function that detects:
  - Wan 2.2 I2V LoRA adapters
  - Wan 2.2 I2V base models
  - Specific known problematic model patterns
- Print warning with suggestion to use --invert_colors flag
- Call warning for both LoRA and non-LoRA model paths

- Replace unreliable auto-detection with explicit user control
- Add --invert_colors CLI argument
- Update SKILL.md documentation with usage example

- Add documentation for --offload_strategy balanced
- Update VRAM management section
- Update troubleshooting section

- New --offload_strategy balanced option
- Loads model fully to GPU if it fits (with 15% buffer)
- Only uses sequential offloading when VRAM is insufficient
- Maximizes GPU utilization while preventing OOM errors

- Use percpu=False to get average across all CPUs
- Prevents false warnings when single thread is at 100%
- Correctly reports 8.3% load instead of 100% on 12-core system

- Detect inverted colors by checking mean brightness
- Automatically invert if mean > 0.7 (indicating mostly white/bright)
- Print warning when color correction is applied

- Handle [-1, 1] range from diffusion models
- Properly normalize to [0, 1] before converting to uint8
- Add clipping to ensure valid color ranges

- Add proper tensor/numpy conversion before export_to_video
- Handle multiple channel formats (NCHW to NHWC)
- Ensure RGB format and uint8 range for video export

Add WanImageToVideoPipeline to i2v_pipelines list so image argument is passed correctly

- Add model ID check for I2V detection (not just tags)
- Add -Diffusers suffix when extracting base model from tags
- Add runtime validation for Wan LoRA base model against tags

For Wan LoRA adapters, skip reading base_model from stored config
(which may have incorrect values like T2V instead of I2V).
Instead, always infer from LoRA ID by checking for 'i2v' in the name.

This ensures wan2_2_i2v_general_nsfw_lora uses the correct
Wan-AI/Wan2.2-I2V-A14B-Diffusers base model instead of the
incorrect Wan-AI/Wan2.2-T2V-A14B-Diffusers.

The check at line 9414 only checked the stored supports_i2v flag
from the model configuration, but didn't check the model ID string
for 'i2v' like the detect_model_type() function does.

Now the I2V validation also detects I2V capability from the model ID,
making it consistent with detect_model_type() and properly detecting
I2V capability for LoRA adapters like lopi999/Wan2.2-I2V_General-NSFW-LoRA.

- Always infer base model from LoRA name, not stored database value
- Fix supports_i2v detection for LoRAs based on LoRA name
- Ensures Wan 2.2 I2V LoRAs use correct I2V base model

- hpcai-tech/Open-Sora-1.2 -> hpcai-tech/Open-Sora-2
- genmo/mochi -> genmo/mochi-1-preview

When selecting a Wan 2.1 I2V model that is a LoRA or tensor weight,
the base model now uses Wan-AI/Wan2.1-I2V-14B-720P-Diffusers instead
of the generic Wan-AI/Wan2.1-I2V-14B-Diffusers.

Fixed ValueError: too many values to unpack (expected 5)
- Line 3929: Added missing 6th element to unpacking
- Line 3936: Added missing 6th element to unpacking

The results tuple has 6 elements:
(name, info, caps, is_disabled, fail_count, orig_idx)

When selecting a Wan 2.1 I2V model that is a LoRA or tensor weight,
the base model now uses Wan-AI/Wan2.1-I2V-14B-720P-Diffusers instead
of the generic Wan-AI/Wan2.1-I2V-14B-Diffusers.

Fixed ValueError: too many values to unpack (expected 5)
- Line 3929: Added missing 6th element to unpacking
- Line 3936: Added missing 6th element to unpacking

The results tuple has 6 elements:
(name, info, caps, is_disabled, fail_count, orig_idx)

Fix I2V pipeline auto-detection

See merge request !1

- Add detect_model_family() to identify model family (wan, sdxl, sd, ltx, etc.)
- Add get_pipeline_for_model_family() for proper pipeline selection based on family + task
- Enhance detect_generation_type() to check --image FIRST for I2V detection
- Add support for --image_model, --prompt_image, --prompt_animation as I2V indicators
- Add support for audio/subtitle options as T2V+V2V chaining indicators

This fixes the issue where SDXL models were incorrectly using WanPipeline
for I2V tasks, causing type mismatch errors (expected UMT5EncoderModel,
got CLIPTextModel). Now SDXL models correctly use DiffusionPipeline
or StableDiffusionXLPipeline.

- Add --model-list-batch to EXAMPLES.md for batch model listing
- Add new CLI options to MCP server (--output-dir, --yes, --audio-chunk)
- Add new CLI options to webapp build_command function
- Update README.md with Output Options section

Added --audio-chunk argument with 3 modes:
- overlap (default): overlapping chunks like [0-60], [58-118]
- word-boundary: uses Whisper timestamps to split at word boundaries
- vad: uses Voice Activity Detection to skip silence

Also added --audio-chunk-overlap to control overlap duration.

New functions added:
- process_video_with_vad(): VAD-based chunking
- process_video_word_boundary(): Word-boundary chunking using Whisper

Modified:
- transcribe_video_audio(): accepts audio_chunk_type and audio_chunk_overlap params
- _transcribe_chunked(): accepts chunk_type and overlap params

Models like Faber8/AbyssOrangeMix2 are SD1.5 models, not Flux.
Now detected as StableDiffusionPipeline instead of FluxPipeline.