ISF and image input size

[Sadler]

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.

[Sadler]

Here's another case. Any shader that draws text from a font atlas, such as the standard 16×16 ShaderToy atlas (1024×1024), can't take the atlas from Magic through an image input as it is. At 1280×720 the atlas is cropped to its middle 720 rows, so most glyphs land in the wrong place or are lost. The only way through an input is an ImageFile module set to Scale: Stretch, which squeezes the whole atlas into the window. That has several costs:

• The result depends on the output resolution. The stretched atlas is resampled to whatever the window happens to be. At 1920×1080 each glyph cell is 67.5 pixels tall, so cell boundaries fall mid-pixel and filtering blends in the edge of the glyph row above or below. The same shader, atlas and settings give different text at 720p, 1080p and 4K, and things set up in rehearsal at one resolution change at another.
• The atlas is resampled unevenly. At 1280×720 each 64×64 cell becomes 80×45: enlarged by 1.25× horizontally and reduced to 0.7× vertically. A third of the vertical detail is gone before the shader reads anything, and any weight or outline control that thresholds the atlas now acts on edges softened differently in each direction. At lower output resolutions this becomes visible distortion in the glyphs.
• The shader can't work on its own. It needs a particular upstream module with a particular non-default setting, and its description has to say so. Anyone who connects an atlas normally gets cropped or misplaced characters with no clue why. I even forget!
• Stretching only works because a regular grid survives filtering. An atlas with an irregular layout, a LUT, or any texture holding packed data has to be read pixel-exact, and resampling corrupts it. For those, Stretch is not a workaround at all.

Screenshot 2026-10-03 170946.png (179.98 KiB) Viewed 479 times

ISF imported images avoid all of this, but are no substitute. I tested images loaded through the shader's own IMPORTED section (37×23 up to 3000×2000, including from a subfolder). Every one arrived at its true size, so Magic can already deliver native-size textures to an ISF. The limitation applies only to image inputs. But an imported image is a fixed path written into the shader file: to change the font you have to edit the .fs, the asset has to ship alongside it, and Magic's file picker, Reload and modifiers can't reach it. So the choice is between a flexible input that degrades the atlas and an exact atlas that can't be changed in Magic. An option to pass an image input at its native size would give both.

[Magic]

In a future version we can probably expose the IMPORTED images as File parameters in the modules. That would be helpful at least, right?

Other than that, the fixed resolution of the pipeline is a fairly core feature and I don’t know if we want to go messing with it any time soon.

[Sadler]

I did some further testing in 2.5 and 3.0. The built-in transforms keep the source's full resolution: scale down then back up and nothing is lost. The degradation happens at the first glsl node that renders, such as an ISF, shader or built-in effects, which render at the downstream resolution. However, with a Resolution node inserted after the shader, set to the content's resolution, restores full quality, because the whole chain then renders at that size. (In my first post above I said a Resolution node didn't help; that was with it placed before the shader.) So for high-resolution sources like 360° footage, put a Resolution node after the shader.

What that can't do is give a shader an input at a different size from its own output, such as a font atlas or LUT, which is where File parameters for imported images would come in. Thanks for the suggestion. The hard coded file path should be the default when no file is configured through the UI and the selection should match existing UI standards.