35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
# Z-Image Notes
|
|
|
|
## Current default assumption
|
|
|
|
- `Z-Image` is in scope for collection and optimization alongside `FLUX.2-klein`, `LTX`, and `MiniMax`.
|
|
|
|
## What to look for
|
|
|
|
- strong official `text-to-image` workflows
|
|
- reference and edit workflows
|
|
- outpaint / inpaint workflows
|
|
- high-quality upscaling or restoration-adjacent workflows
|
|
- any workflow that clearly beats a comparable `FLUX` path in practical image quality or simplicity
|
|
|
|
## Strong current source workflows
|
|
|
|
- `models/zimage/z-image-turbo-official-example/`
|
|
- `models/zimage/z-image-turbo-inpainting-community/`
|
|
- `models/zimage/z-image-turbo-controlnet-union-community/`
|
|
- `models/zimage/qujincheng-z-image-lora-facetailer/` for face-detail follow-up, not as a core generator
|
|
|
|
## Current heuristics
|
|
|
|
- Prefer real workflow assets over showcase pages.
|
|
- Favor workflows with clear node requirements and portable imports.
|
|
- Treat `Z-Image` as especially relevant for image-generation and image-edit categories, not video categories.
|
|
- Keep the official example as the clean text-to-image baseline, then compare the community inpaint and controlnet-union graphs against it for real edit gains.
|
|
- Treat facetailer-style graphs as post-pass helpers unless they prove they can stand alone.
|
|
|
|
## What still needs proof
|
|
|
|
- which `Z-Image` workflows are genuinely stronger than the best current `FLUX` image-generation paths
|
|
- whether `Z-Image` should become a category-master candidate for `text-to-image` or `image-edit`
|
|
- whether the inpaint or union-style community graph is the better maintained edit baseline on Chris's machine
|