evilsocket

/

alucard

Like 2

Thank you for releasing Alucard, the dataset, and the training code. We are evaluating it for pixel-art game assets and investigated soft/noisy RGBA outputs using both the upstream API and our local integration. We would appreciate help confirming the expected output for the documented recipe, or identifying a known-good checkpoint/environment.

The main finding: we can reproduce the issue directly with upstream Alucard, and our integration produces identical pixels under matched conditions. Checking earlier weights and several inference variations did not recover clean sprites. This does not establish that a training failure occurred; we may still be missing an environment or training/inference detail.

Minimal reproduction

Upstream code tested: 02d1c60a16142015f7838a6a033da5e6ac9ce4f7. The following uses the model card's wizard recipe and pins the tested weight revision:

from alucard import Alucard
from huggingface_hub import hf_hub_download
import numpy as np

weights = hf_hub_download(
    "evilsocket/alucard",
    "alucard_model.safetensors",
    revision="b8e7602fc8e676d0b0bc0abb11d2cda665c560d8",
)
model = Alucard.from_pretrained(weights, device="cpu")
sprite = model(
    "a pixel art wizard sprite",
    num_samples=1,
    num_steps=20,
    cfg_text=5.0,
    cfg_ref=2.0,
    seed=42,
)
sprite.save("alucard-wizard.png")
alpha = np.asarray(sprite.convert("RGBA"))[..., 3]
print("partial alpha fraction:", ((alpha > 0) & (alpha < 255)).mean())

Observed: a recognizable but fuzzy figure with background texture; all 16,384 pixels have alpha strictly between 0 and 255 (partial alpha fraction: 1.0). We expected a more clearly defined sprite and useful transparent background. Partial alpha alone is not evidence of a broken model; the visual softness, background noise, and weak response to different subjects are the practical concerns.

Original CPU output, without post-processing.

We also checked CUDA on an RTX 5080 (16 GB). The final diagnostic environment was Python 3.11, PyTorch 2.10.0+cu128, OpenCLIP 3.3.0, FP32 inference. CPU and CUDA use different noise streams, so we compare implementations on the same device, rather than expecting identical CPU/GPU pictures.

Checks and comparisons

The final sampler comparison used four prompts with the same CUDA noise seeded with 42, text CFG 5, no reference: wizard, knight, dragon, and slime. In particular, the model-card dragon prompt produced noisy textures in these tests. No experimental correction was retained as a quality fix.

Separate sampler edge cases

While reviewing sample.py, we found two control behaviors worth flagging independently:

• With no reference, cfg_text < 1 takes the non-CFG branch and ignores the requested fractional/zero scale.
• With cfg_text > 1 and a supplied reference, cfg_ref == 1 drops the reference because the reference branch only runs for cfg_ref > 1.

Applying the documented equation consistently resolves these cases:

v_guided = v_uncond + cfg_text * (v_text - v_uncond)
if ref is not None:
    v_guided += cfg_ref * (v_both - v_text)

We verified zero, fractional, unit and amplified scales with a small deterministic test model. Neither edge case explains the original text-only wizard output, and fixing them preserves the original default recipe exactly. We also fixed batch-seed reporting and cancellation/progress in our integration; those are integration changes, not evidence of an upstream quality cause.

Would you be able to share a known-good output and its checkpoint/seed, the intended CLIP version/activation, or a raw-versus-EMA checkpoint comparison? Any recommended baseline would help us distinguish a setup mismatch from limitations of these particular weights. Thanks again for making the project available.