PVL_fal_LumaPhoton_FlashReframe_API

Luma Photon's "flash" tier is the same reframe idea as the pack's standard LumaPhoton Reframe node - take an image, fit it into a target aspect ratio, paint the new space - but tuned for speed and lower cost. If you're iterating on compositions, testing several aspect ratios, or reframing a batch of frames where the standard model would be overkill, this is the one to reach for. The trade is a step down in fine detail compared to the full Photon endpoint, which rarely matters when the whole point is deciding whether a composition works.

It's part of the ComfyUI Assistant Node pack from pvlprk, and it's the pack's fastest path between "image at one ratio" and "image at another ratio."

How it works

Identical structure to its sibling: image and aspect_ratio (1:1, 16:9, 9:16, 4:3, 3:4, 21:9, or 9:21; default 16:9) are the only required inputs. The image is base64-encoded and posted to fal-ai/luma-photon/flash/reframe, the job is polled, and the result downloads as an IMAGE tensor. The same optional controls are there, each defaulting to -1 (off): prompt to steer what gets painted into the extended area, grid_position_x/grid_position_y to position the source within an output grid, and x_start/x_end/y_start/y_end to crop the source region before reframing.

The "flash" difference is entirely in the serving: faster queue times, lower per-call cost, and slightly less polish on the reconstructed regions. For composition checks and ratios tests, that's the right trade.

The inputs that matter

• image - the source.
• aspect_ratio - the target shape.
• prompt (optional) - what to paint into the new space.

Output: one IMAGE.

Installing it

Part of pvlprk/comfyui-pvl-api-nodes. ComfyUI Manager (search "ComfyUI Assistant Node") or:

cd ComfyUI/custom_nodes
git clone https://github.com/pvlprk/comfyui-pvl-api-nodes

Set FAL_KEY (or FAL_API_KEY / FAL_CLIENT_KEY), restart, add credits.

Where people get burned

Same pack-wide pitfalls: missing FAL_KEY, and errors that show up as a blank placeholder rather than a clean failure - check the console. The flash-specific expectation trap is treating it as a drop-in for the full Photon node on final deliverables; it's the iteration tier, so when a reframe has to be the image, re-run it on the standard endpoint. And keep the source region tight with the crop inputs when you care about what survives - less margin for the model to improvise.