🌳 Poplar: A Scalable Pipeline for Human-Centric Image Dataset Synthesis

Zhishan Zou^1
1Beijing University of Posts and Telecommunications

         

Poplar is a reproducible and resumable Specify → Render → Inspect pipeline for constructing customizable human-centric image-text datasets. Instead of optimizing isolated generations, Poplar makes collection-level semantic coverage, rendering provenance, and quality-control decisions explicit and auditable.

• 😊 [2026/08/03] We release the human-centric image dataset Poplar-9K on Hugging Face and ModelScope.
• 🔥 [2026/08/01] We release the complete Poplar pipeline, configurations, and reproducibility contract.

Poplar connects three replaceable stages through append-only JSONL records:

1. Specify samples structured subject, clothing, activity, scene, capture, and lighting attributes under commonsense compatibility constraints. Qwen3.5-27B-FP8 verbalizes each valid specification as a photography-oriented prompt without selecting or changing its canvas.
2. Render produces one image per specification with Krea 2 Turbo and the Krea2-realism-V2 adapter. A conservative deterministic prefilter retries near-grayscale, severely blurred or low-detail, and corrupt outputs.
3. Inspect invokes Qwen3.5-27B-FP8 once per image-prompt pair. It rejects intrinsic defects and critical or major prompt mismatches while preserving the generation prompt byte-for-byte.

Poplar separates what the dataset should contain from how each sample is described. The semantic layer specifies people, clothing, activities, and scenes; the capture layer describes photographer perspective, device, framing, lighting, and plausible non-studio characteristics. This makes the planned dataset composition inspectable before any image is rendered.

Technical file checks alone cannot identify prompt mismatches, duplicated subjects, stitched layouts, implausible interactions, cropped faces, anatomy errors, or sensitive content. Poplar records structured defect flags, mismatch severity, visible evidence, and confidence for every reviewed candidate. Rejected records remain available for auditing but never enter the curated release.

git clone https://github.com/choucisan/poplar.git
cd poplar

• Linux and Python 3.10
• NVIDIA GPUs with a driver compatible with the CUDA 12.6 PyTorch wheels
• Four GPUs for the released schedule
• Access to the model repositories declared in configs/poplar_pipeline.json

The reference schedule uses GPU 0 for Specify, GPUs 1-2 for the sharded Krea renderer, and GPU 3 for Inspect. Stages execute in dependency order; GPUs do not need to host all models simultaneously.

With Conda:

conda env create -f environment.yml
conda activate poplar

With uv:

uv sync --python 3.10
source .venv/bin/activate

Authenticate with Hugging Face when a model requires license acceptance:

hf auth login

Hugging Face environment variables are respected without code changes. Use HF_HOME to select a cache directory and HF_ENDPOINT to select an explicit mirror.

Validate paths and configuration values and print every subprocess without loading model weights or creating run artifacts:

bash scripts/run_pipeline.sh --dry-run

bash scripts/run_pipeline.sh

The launcher selects the project uv environment or the active Conda environment and invokes pipeline.py. Every stage appends records and skips completed identifiers, so the same command safely resumes an interrupted run. Shards are merged only after the expected number of records is present.

Run selected stages when their dependencies already exist:

bash scripts/run_pipeline.sh --stages specify
bash scripts/run_pipeline.sh --stages render inspect

Poplar does not hard-code the Poplar-9K dataset size. Assign each scaled run a distinct name so its resumable records remain isolated:

# Small validation run
bash scripts/run_pipeline.sh \
  --candidate-count 100 \
  --run-name poplar_100

# 100K-candidate construction run
bash scripts/run_pipeline.sh \
  --candidate-count 100000 \
  --run-name poplar_100k

Candidate indices are distributed deterministically across the configured Specify and Inspect GPUs, including uneven totals. The released Krea renderer shards one model instance across exactly two visible GPUs. Running multiple renderer instances requires an external job scheduler.

When resuming selected stages, repeat the same --candidate-count and --run-name values used to create the run.

Local model directories can override Hugging Face identifiers without editing the released configuration:

export POPLAR_PROMPT_MODEL=/models/Qwen3.5-27B-FP8
export POPLAR_RENDER_MODEL=/models/Krea-2-Turbo
export POPLAR_RENDER_ADAPTER=/models/Krea2-realism-V2
export POPLAR_INSPECT_MODEL=/models/Qwen3.5-27B-FP8

bash scripts/run_pipeline.sh

POPLAR_RENDER_ADAPTER may point to an adapter directory or directly to its .safetensors file. Set POPLAR_CONFIG to run a separate configuration file and POPLAR_PYTHON to select an explicit Python interpreter.

The default Poplar-9K run writes:

prompts/poplar_9k/
├── prompts_shard_0.jsonl
└── prompts.jsonl
outputs/poplar_9k/
├── realism_*.png
├── manifest.jsonl
├── rejected_prefilter/
└── reviews/
    ├── review_shard_0.jsonl
    ├── review.jsonl
    ├── keep.jsonl
    ├── reject.jsonl
    └── summary.txt
logs/poplar_9k/

The records implement the reproducibility contract described in the paper:

• Prompt records: immutable prompt and SHA-256 hash, taxonomy version, structured attributes, canvas, and requested rendering seed.
• Rendering manifest: model and adapter identifiers, dimensions, requested and actual seeds, inference settings, accepted prefilter metrics, and retry history.
• Review records: rubric version, model identifier, defect flags, prompt mismatches and severity, visible people, evidence, confidence, and timestamp.
• Release manifests: separate auditable keep/reject decisions that retain the original prompt and provenance; rejected items additionally retain failure categories and visible evidence.

Run artifacts, generated images, model caches, and logs are ignored by Git.

poplar/
├── configs/
│   ├── poplar_pipeline.json       # Released Poplar-9K construction policy
│   ├── realism_taxonomy.json      # Attribute spaces and compatibility rules
│   └── review_rubric.txt          # Inspection criteria and output schema
├── scripts/
│   ├── run_pipeline.sh            # One-command launcher
│   └── merge_review_shards.py     # Deterministic review merge
├── tests/
│   └── test_release_contract.py   # Configuration and provenance tests
├── pipeline.py                    # Unified Specify-Render-Inspect CLI
├── generate_prompt_shard.py       # Structured sampling and prompt generation
├── merge_prompt_shards.py         # Deterministic prompt merge
├── krea_pipeline.py               # Rendering, prefilter, retry, and manifest
├── review_images.py               # Immutable-prompt VLM inspection
└── filter_reviewed.py             # Keep/reject manifests and statistics

The release-contract tests do not load model weights or require a GPU:

python -m unittest discover -s tests -v

They validate the full dry-run command graph, scaled-run namespacing, immutable prompts, and preservation of rejection evidence.

@misc{zou2026poplar,
  title        = {Poplar: A Scalable Pipeline for Human-Centric Image Dataset Synthesis},
  author       = {Zhishan Zou},
  year         = {2026},
  eprint       = {2608.00440},
  archivePrefix = {arXiv},
  primaryClass = {cs.CV},
  doi          = {10.48550/arXiv.2608.00440},
  url          = {https://arxiv.org/abs/2608.00440}
}

Poplar builds on the following open models and libraries:

• Language and vision-language model: Qwen3.5-27B-FP8
• Image generator: Krea 2 Turbo
• Realism adapter: Krea2-realism-V2
• Infrastructure: PyTorch, Transformers, Diffusers, and Accelerate

For questions, corrections, or collaboration requests:

choucisan@gmail.com