Colorspace detection requires extra memory that may not be available
when using offload strategies (sequential, balanced, auto_map, group).
Now skips detection and defaults to RGB for:
- Any offload strategy other than 'none' or 'model'
- Systems with <12GB available RAM

Users can still manually set colorspace or use --swap_bgr if needed.

- Check available RAM before detection (skip if <8GB free)
- Reduce test dimensions from 256x256 to 128x128
- Reduce inference steps from 10 to 5
- Lower guidance scale from 5.0 to 3.0
- Clear memory before and after detection
- Catch OOM errors specifically with fallback
- Always clear memory on any error

The balanced offload strategy existed in two places in the code.
The first occurrence at line 9384 was still using the old logic.
Now both occurrences have the improved VRAM estimation with:
- LoRA overhead accounting
- Inference overhead (30%)
- Conservative 70% threshold
- OOM fallback protection

- Account for LoRA overhead (~4GB) in VRAM calculations
- Add 30% inference overhead for activation memory
- Use more conservative 70% threshold (was 85%)
- Add OOM fallback to model CPU offload if GPU loading fails
- Switch fallback from sequential to model offload for better performance

- Add detect_model_colorspace() function to detect colorspace by generating test red frame
- Add get_model_colorspace() helper to retrieve or detect colorspace
- Modify frame processing to auto-swap BGR based on model config
- Preserve --swap_bgr flag as manual override
- Colorspace is saved to model config (~/.config/videogen/models.json) after first detection

- Replace hardcoded warning with explanation of why automatic detection isn't possible
- Document --invert_colors for luminosity inversion
- Document --swap_bgr for BGR<->RGB channel swapping
- Explain that VAE output format is model-specific

- Remove warn_if_inverted_colors_likely() function (was just assumptions)
- Add --swap_bgr flag to swap BGR<->RGB color channels
- Keep --invert_colors for luminosity inversion
- Users can now manually specify color correction needed

There is no standard way to detect RGB vs BGR output from models - it's model-specific.

- 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)