The arcminute figure is doing all the work here, and it is worth saying why it collapses the tiering rather than just resizing it. Required PPI is 3438 divided by viewing distance in inches [7]. Print dimensions go up with the product. People stand back from big things roughly in proportion to how big those things are, so the two terms cancel inside the pixel budget: the tapestry has about twenty times the surface area of the small canvas and is viewed from three times the distance [14].
Run the discarded rule to its conclusion. Applying 300 PPI to a 4x6 ft tapestry means 21,600 by 14,400 pixels, which is an uncompressed RGBA buffer of roughly 1.16 GB [1]. Nothing in a serverless function holds that, and no viewer six feet away could tell it apart from 3438 pixels on the long edge [11]. Even the cautious 8192px upscale that was OOM-killing the pipeline carries about 5.7 times more pixels than the largest product in the catalogue actually requires [5].
The author says the giant tapestry and the small canvas need almost the same pixel count [15]. His own table says 3438 and 2292, which is 1.5x on the linear edge and 2.25x in pixels [3]. That is not identical, and the gap matters if you are choosing a single render target: 4096px sits about 19 percent above the largest requirement in the table [2], so the tapestry is rendered with modest headroom and the desk canvas is rendered with a lot of waste. The virtue of one target is not that it is tight. It is that the waste is bounded and computed, instead of being a 4x reflex applied to whatever the model handed you.
Bleed is the part that survives the correction. A 12x16 canvas on 1.5 inch stretcher bars means feeding a 15x19 inch image [21], and 19 inches at the 143 PPI that two-foot viewing demands is about 2,720 pixels on the long edge [4] - still comfortably inside 4096. So the frame wrap adds roughly a fifth to the requirement, while the habit of upscaling everything added a multiple.
The sequencing fix is the cheaper half and gets the least attention. Serve the preview from the raw 1024px generation and render the print file after checkout, when you know which size was bought [22]. Upscaling in the request path means paying GPU seconds for images nobody purchases [23], and it also means the memory spike lands in an HTTP handler, where an intermittent OOM reads as a flaky endpoint rather than a capacity decision you made a month earlier [18].
