Guide
Cropping sprites without losing pixels
Cropping sounds trivial until the result is one pixel off, or slightly blurry, and you cannot work out why.
Screen pixels are not image pixels
This is the root of most cropping problems. When you view a 64×64 sprite zoomed to 800%, every image pixel covers an 8×8 block on screen. If the crop rectangle is tracked in screen coordinates and converted at the end, the conversion divides by the zoom factor and lands on a fraction — 12.375 image pixels rather than 12.
Something then has to resolve that fraction. Rounding shifts your crop by up to half a pixel. Resampling blends neighbouring pixels together, which turns a crisp one-pixel outline into a two-pixel smear. Worst of all, the result depends on your zoom level, so the same crop gives different output depending on how far you happened to be zoomed in.
The fix is to define the crop in original image pixel coordinates from the start and treat the screen purely as a viewport. CropViewer works this way: the rectangle is stored in image pixels, and zooming or panning cannot change what gets exported. The inspector shows the exact numbers, and you can type them directly.
Type the numbers when it matters
Dragging is fine for finding a region roughly. For anything that has to be exact — a tile that must be exactly 32×32, a frame that must line up with its neighbours — type the values.
A frame from a sprite sheet with 64×64 cells, third column, second row, is X = 128, Y = 64, W = 64, H = 64. That is far quicker and far more reliable than trying to drag onto it, and it is the same arithmetic every time.
Arrow keys nudge the region one pixel at a time, which is the right tool for the last small correction after dragging.
Trimming transparent padding
Sprites exported from a 3D tool or an animation package often arrive centred in a much larger transparent canvas. Trimming that padding reduces file size and, more importantly, reduces wasted space when the sprites are packed into an atlas.
Two things to be careful about:
- Trim consistently across an animation. If you trim each frame to its own tight bounds, the frames no longer share an origin and the sprite will jitter as it plays. Find the bounding box that contains every frame and crop all of them to that same rectangle.
- Watch for nearly-transparent pixels. Anti-aliased edges and soft shadows fade to very low alpha rather than to zero. A crop that looks like it only removed empty space may have clipped the outer edge of a glow. Zoom in and check the boundary before committing.
What rotation does
Cropping on an axis-aligned rectangle is a pure copy: output pixels correspond one-to-one with input pixels, and nothing changes.
Rotating the crop rectangle is fundamentally different. The output grid no longer lines up with the input grid, so every output pixel has to be interpolated from several input pixels. That is unavoidable — it is a property of rotating a raster image, not a flaw in any particular tool — and it means a rotated crop is always slightly softer than the original.
Practical consequences:
- Rotate once, from the original, rather than repeatedly. Each rotation resamples what the last one already softened.
- 90° steps are the exception: they move pixels without resampling, so they are lossless. Use the rotate-left and rotate-right buttons for those rather than typing 90 into the crop rotation field.
- For pixel art, avoid rotating at arbitrary angles entirely. There is no interpolation that makes it look right.
Aspect ratios and power-of-two sizes
Lock an aspect ratio when a set of images has to be uniform — portraits, card art, thumbnails. In CropViewer the ratio lock applies to dragging as well as typing, and holding Shift while dragging a corner preserves the current ratio even when no preset is selected.
Power-of-two dimensions (16, 32, 64, 128…) used to be a hard requirement for GPU textures. Modern hardware accepts arbitrary sizes, so for sprites packed into an atlas it usually does not matter. It still does matter in two cases: textures that need mipmaps, which halve cleanly only from power-of-two sources, and tiling textures, which need to repeat without a seam.
Keep the original
Crop to a new file rather than overwriting the source. You will want the original the first time a crop turns out one pixel tight, or an art direction change needs more headroom.
CropViewer's Quick Save Crop does this by default: it writes
hero_crop.png next to hero.png and numbers
subsequent saves hero_crop_001.png and so on, so it never
silently replaces anything. There is an option to collect these in a
/cropped subfolder instead if you prefer them separated.