Contact sheet layout generator

It reports the number of columns and rows, thumbnail width and height, and final sheet dimensions. The layout preserves room for every source aspect ratio, stays within the width limit, and is produced by deterministic arithmetic that gives the same result every time.

Prepare the image dimensions and width limit

Start with one record for every image that will appear on the contact sheet. Each record needs a width and height in pixels, and both values must be positive whole numbers. The files themselves are not uploaded or decoded: only their dimensions are needed. Include every image because the number of records determines how many grid cells must be available, while the widest and tallest source dimensions define a common bounding-box shape that can contain the full collection without cropping. Then set max_sheet_width to the pixel width available in your document, export, gallery panel, or print workflow. The calculator treats that value as a hard ceiling. It does not reserve space for external page margins, captions, gutters, borders, or printer bleed, so subtract those allowances before submitting if another system will add them later. A list with zero images is rejected because columns, rows, and thumbnail size have no useful meaning when there is nothing to place. Invalid, fractional, zero, or negative dimensions are also rejected rather than silently repaired, keeping automated layout pipelines predictable.

Understand how the grid is selected

The solver evaluates every feasible column count from one through the number of images. For each candidate it calculates the required row count with a ceiling operation, divides the maximum sheet width into equal integer-width cells, and derives a matching thumbnail height from the overall source-dimension envelope. This creates a uniform thumbnail box suitable for contain-style placement: a renderer scales each image proportionally until it fits inside that box, potentially leaving unused space on one axis but never requiring a crop. The solver compares the resulting sheet width and height and selects the candidate closest to a square. A compact, balanced sheet is generally easier to scan and avoids the extreme one-column strip that merely maximizing thumbnail size would produce. If two candidates are equally square, the one offering greater thumbnail area wins. If they remain tied, fewer columns wins, which makes the final choice explicit and stable. Thumbnail width is also capped at the widest source width, avoiding unnecessary upscaling when a generous sheet limit is supplied. All calculations use integer pixels and deterministic tie-breaking.

Use the result in a renderer or production pipeline

The response supplies count, columns, rows, thumbnail_size, sheet_size, max_sheet_width, and the fit mode. Create a canvas using sheet_size.width and sheet_size.height, then place item index i at column i modulo columns and row floor(i divided by columns). Each cell has the returned thumbnail width and height. Scale the source with a contain operation, center it in the cell if desired, and preserve its original aspect ratio. Because the last row may not be full, your renderer can leave trailing cells blank or center that row as a separate presentation choice; the calculated canvas deliberately keeps simple rectangular grid geometry. The result excludes gutters and captions. To add a ten-pixel gap, for example, either reserve the total gap width before calling the calculator or treat the returned thumbnail dimensions as a starting point and reduce each cell consistently. The endpoint is useful both interactively and in repeatable batch jobs: identical input produces identical output, it makes no network requests, and it never inspects image content. API use costs $0.002 per request, while browser execution can use the same pure calculation locally.