ISF and image input size
Posted: Tue Sep 29, 2026 11:18 am
Magic supports images larger than the output dimensions in all of its transforms - even when the image node is fitted to the output, the full resolution is available. This preservation of image data and dimensions does not pass to interactive shaders.
Images larger than the output resolution get cropped and images smaller get padded. This means that IMG_SIZE is always equal to RENDERSIZE. There are many use cases where sending a larger or smaller image to an interactive shader would be beneficial. One of those is 360 projection where a 5k source is downscaled to the output resolution (assuming HD) to then be projected. Another use case is sprite atlases which may be larger or a different aspect ratio from the output. The simplest case of rotation in ISF will crop the image if it is not scaled to fit within the window.
Even is a resolution node comes before the ISF, the resolution is not respected. ISF supports different dimensions for each image input.
This is also a gotcha for many users who can't figure out why their output is being cropped by shaders.
Images larger than the output resolution get cropped and images smaller get padded. This means that IMG_SIZE is always equal to RENDERSIZE. There are many use cases where sending a larger or smaller image to an interactive shader would be beneficial. One of those is 360 projection where a 5k source is downscaled to the output resolution (assuming HD) to then be projected. Another use case is sprite atlases which may be larger or a different aspect ratio from the output. The simplest case of rotation in ISF will crop the image if it is not scaled to fit within the window.
Even is a resolution node comes before the ISF, the resolution is not respected. ISF supports different dimensions for each image input.
This is also a gotcha for many users who can't figure out why their output is being cropped by shaders.