Jakkanna RealityScan Save Image Set

JakkannaRealityScanImageSetSave is the end of the line for the RealityScan Fast and Production workflows. It takes the 81 SCAIL-2 replacement frames you just generated, the SAM 3.1 track that follows your subject, and a validated track report - and writes a proper turntable dataset to disk: per-frame masked RGB images, per-frame binary masks, and a manifest that describes every byte.

Why would you care? "RealityScan" here isn't photogrammetry. The idea is that you've animated a character with SCAIL-2 (a reference image plus a driving video plus masks - no skeleton, on a Wan 2.1 base), and now you want a 3D asset you can spin around. This node bakes those 81 replacement frames into a clean, mask-separated turntable of your character at consistent angles, which is exactly the input the pack's tools/run_scail_proxy_asset.sh script wants. That script rebuilds pose 0 with its exact Pose Studio camera, rejects self-occluded samples, aligns the masks, and writes JakkannaSCAILProxy.glb with a 2048-pixel unlit texture. RealityScan alignment is optional validation - the asset geometry comes from the mannequin, not from the frames. If you don't care about a 3D proxy, this node is still a tidy way to get a clean 81-shot turnaround of a generated character.

The node is deliberately strict, and that's a feature, not a bug. It will not half-save. It checks, in order: exactly 81 frames (SCAIL-2's native window - one of the few hard facts about the model, per the KB), 704x1280 resolution, exactly one tracked subject, the track report describing the same, no empty mask on any frame. Only then does it project each SAM mask to full resolution, black out everything outside it, and write:

• layers/.geometry/frame_0000.png … - the masked RGB frames
• layers/.mask/frame_0000.png … - binary masks
• manifest.json - per-frame turntable angle (360° / 81 per step), mask area in pixels, and a SHA-256 for every file

That per-file hashing matters. Because everything gets fingerprinted, a swapped or corrupted frame is detectable later, and the manifest is what a downstream pipeline can trust. It writes the images as plain 16-bit-depth-safe PNGs via OpenCV, so don't expect ComfyUI's embedded-workflow metadata to ride along - the file's identity is its hash, and the manifest carries that.

Inputs you'll set:

• images - the 81-frame IMAGE batch out of the sampler
• track_data - the SAM3_TRACK_DATA from SAM 3.1
• track_report - STRING, forceInput; wire this from a Jakkanna validate node, don't fake it
• expected_frames - INT; it checks this against 81
• dataset_prefix - default Jakkanna/RealityScan/turntable, the folder under ComfyUI/output/

Outputs: dataset_path and manifest_path, both STRINGs - the paths you hand to the proxy-asset script.

Install: ComfyUI Manager, search "Jakkanna", or:

cd ComfyUI/custom_nodes
git clone https://github.com/teenu/ComfyUI-VNCCS-Utils-Maintained
cd ComfyUI-VNCCS-Utils-Maintained
pip install -r requirements.txt

Restart after. Don't install this alongside the upstream vnccs-utils - same node names, guaranteed conflict. And remember the pack doesn't download the SCAIL-2, SAM 3.1, or Krea 2 weights for you; the bundled workflows expect them already in your models folders. The lossless FFV1 master side of these workflows also wants VideoHelperSuite 1.7.9+.

The trap: people wire a fresh images batch but skip the validate node and try to feed a made-up string into track_report. It will refuse - the report must describe an 81-frame single-subject track or nothing gets written. That's the whole point: this node only ever emits complete, verifiable datasets.