Atlas Object Crop 🎯

Almost every pixel-aligned image-to-3D model assumes something quietly false about your photo: that the subject sits dead centre, shot with a centred pinhole. Pixal3D was published at a specific framing for exactly that reason. Your photograph has a castle in the left third.

So you can't just hand ImageCropToMask's output to the model. Cropping moves the principle point. Atlas Object Crop 🎯 doesn't cut the photo - it re-renders the object through a virtual camera that shares the solve's centre and is rotated to look straight at the object, using an exact rotation homography with gravity roll. The changelog claims Pixal3D's own projection is reproduced to 0.01 px.

Two consequences follow, and both matter downstream. The model sees the object framed the way it expects, and fov comes from the solve, not from a depth model's guess - which is what makes the mesh placeable back in the scene at all.

Inputs and outputs

Required: solve; image (the source photo the solve was made from); mask - the ONE object to lift, visible pixels only. In a typical Atlas graph that mask arrives from AtlasSAM3Mask → AtlasInstanceMask, so the same segmentation model that drives your masking elsewhere does double duty here.

Optional: pad (1.1 - margin around the object, and 1.1 is the framing Pixal3D was published with, so don't touch it unless you have a reason); size (1024 - Pixal3D expects 1024); roll (gravity by default, because world-up-is-up matches the model's upright-object prior; source_camera keeps the photo's own roll if you'd rather not fight it); background (black, white, gray, photo - black matches ImageCropToMask, photo keeps surrounding context for the model to trip over); grow_px (0 - dilate the mask before cropping, in source pixels).

Outputs: crop (IMAGE → the conditioning model), crop_mask (MASK), fov (FLOAT, horizontal degrees), object_crop (the handle AtlasImportGeneratedMesh needs), report.

That fov wiring is a real trap in this pack: wire it into Pixal3DConditioning.fov, never into MoGeGeometryToFOV. The solve measured your focal length; a monocular geometry model is inferring one. Substituting the inference here throws away the only part of this pipeline that's actually measured.

Install

cd <ComfyUI>/custom_nodes
git clone https://github.com/mikejamesvfx/atlas-camera.git

Or Manager → atlas-camera (ComfyUI Registry entry). Restart. The node is pure Python, so there's no pip step and no GPU requirement of its own - the GPU is spent in the Pixal3D pass after it. MIT, Python 3.10+.

The lane needs ComfyUI V135+ and four model files from the Comfy-Org/Pixal3D repack: pixal3d_int8_convrot.safetensors under models/diffusion_models/pixal3D/, trellis_2_shape_vae_bf16.safetensors and trellis_2_texture_vae_bf16.safetensors under models/vae/, and dino_v3_L_naf_fp32.safetensors under models/clip_vision/. Grab the pack's research workflow in research/ for the end-to-end wiring; the docs are upfront that this lane is newer than the shipping examples.

One folder note, since it confuses people: this node lives under Atlas/advanced in the Add-Node menu, and advanced is where the pack keeps gated and merely advanced nodes. This one registers on a default install - you don't need ATLAS_EXPERIMENTAL=1.

Expectations, honestly set

Generate a body for a static prop or a background filler and you'll be pleased. Expect the output to be a starting block, not a game-ready asset - the topology from every open image-to-3D model is triangle soup and no one has cracked that. Budget for max_faces decimation on the import node and for the gate refusing a mesh whose scale it can't verify against the scene depth. And read the licence line before commercial work: Pixal3D's code is MIT, but its weights' commercial status hasn't been confirmed upstream.