DEV Community: Whispart

An honest wall-art preview needs two sizes

Whispart Studio — Wed, 09 Sep 2026 04:50:15 +0000

A wall-art preview can show the right image at the wrong scale. One common source of error is treating the artwork's image area and its framed outer dimensions as the same rectangle.

This matters to studios such as Whispart, where a selected GAN image is developed into a framed physical work. The frame, surrounding wall and viewing distance are part of the presentation. A preview should make those decisions visible enough for a viewer to reason about them.

Here is a small geometry model for a front-facing, schematic preview. All dimensions below are illustrative, not specifications for a Whispart product.

Store the outer dimensions explicitly

Suppose the visible image is 50 × 50 cm. A hypothetical frame adds 2 cm on each side, with no mat or gap:

outer width  = 50 + 2 + 2 = 54 cm
outer height = 50 + 2 + 2 = 54 cm

If the same design includes a mat, a float gap or a different overlap, that formula changes. A production product page should use confirmed outer dimensions rather than deriving them from an attractive border drawn in CSS.

For a 240 cm-wide wall represented by a 720 px canvas, the scale is 3 px per cm. The image area is 150 px wide; the complete framed object is 162 px wide. Placing the frame outside an element that already represents the outer size would count it twice.

Element	Real dimension in this example	Preview dimension
Wall width	240 cm	720 px
Image width	50 cm	150 px
Frame face, each side	2 cm	6 px
Complete framed width	54 cm	162 px

Preserve the artwork's aspect ratio

For a schematic component, keep the image and the surrounding frame separate:

<figure class="work">
  <img src="artwork.jpg" alt="Complete artwork preview">
</figure>

/* Example only: 3 screen pixels represent 1 cm. */
.work {
  box-sizing: border-box;
  width: 162px;
  margin: 0;
  border: 6px solid #6f5947;
}
.work img {
  display: block;
  width: 100%;
  height: auto;
}

With the square source image in this example, the content is 150 × 150 px and the outer object is 162 × 162 px. A non-square source keeps its own ratio; this snippet does not force it into a square opening.

The colored border is a schematic frame, not a photograph or material simulation. If a real frame overlaps the image, show the resulting visible area explicitly. Do not let object-fit: cover silently decide which part of the artwork disappears.

Say how the scale was established

A measured wall elevation gives a defensible scale for this simple model. An arbitrary room photograph does not. A sofa of unknown size is not a reliable measuring instrument, and perspective changes the apparent scale across a photograph.

When dimensions are unknown, call the image a styling illustration. When a preview is based on measurements, show the dimensions used and the limits of the model. A flat elevation does not predict a surface's texture, reflections or appearance in evening light.

Before deciding on a size, a viewer can mark the proposed outer rectangle on the wall with a suitable removable paper template, then look from the doorway and the usual seated position. This provides a physical scale check without pretending to reproduce the artwork's material presence.

The Whispart process journal treats framed-room visualizations as decision aids and physical proofing as a separate step. That is a useful boundary for preview design: help someone judge placement and proportion, while identifying which qualities the preview cannot demonstrate.

Published by Whispart. This article was drafted and checked by an AI assistant using Whispart's public process documentation. The component and measurements are teaching examples, not a deployed Whispart feature or a specification for an available artwork.

Print preflight for generative art: pixels, crop and physical proof

Whispart Studio — Wed, 09 Sep 2026 04:37:16 +0000

An image export can pass every file check and still fail as a physical artwork. For anyone building a generative-art export tool, separating those two kinds of approval makes the workflow easier to understand.

Whispart develops GAN-based images and gives selected works a physical form. Its process includes human curation, writing, material proofing and a release decision. The checklist here translates that published approach into practical preflight questions; it does not describe an existing automated Whispart print service.

Calculate resolution at the intended size

Pixel dimensions describe a file. Physical dimensions describe an object. The relationship is:

effective PPI = pixels along an axis / (print size in cm / 2.54)

For an illustrative 4096 × 4096-pixel image:

Square print size	Effective PPI, rounded
40 × 40 cm	260
50 × 50 cm	208
60 × 60 cm	173

These are arithmetic examples, not Whispart product specifications or pass/fail thresholds. A print provider should specify the file requirements for the actual process, material and intended viewing conditions.

If the image is cropped, calculate from the pixels that remain. If it is enlarged computationally, record both the original dimensions and the delivered dimensions. A larger pixel count does not by itself establish that the enlarged image contains convincing detail.

Changing only a file's resolution metadata does not add pixels. A useful export interface should therefore show the intended physical size beside the dimensions, rather than celebrating a “300 PPI” label in isolation.

Separate the front image from the edge treatment

A stretched canvas introduces a second geometry problem: what appears on the front, and what is reserved for the sides or finishing process?

Keep the approved complete image separate from any production derivative. Ask the fabricator for the actual allowance and edge treatment before exporting. Do not assume that every canvas depth or frame uses the same dimensions.

A review should make any crop visible. If a face sits close to the edge, a production allowance can change the composition even when the center looks identical. A preview that shows only the front rectangle can conceal that problem.

Give each check a truthful result

Check	What software can report	What still needs inspection
File opens	Decoding succeeded; dimensions read	Whether the image is the intended version
Size calculation	Effective PPI for the selected crop and size	Whether the print is convincing at the intended distance
Crop preview	Which pixels remain on the front	Whether the altered composition is acceptable
Color preparation	The file's declared profile and export settings	The result on the actual material under real light
Production proof	A proof record has been attached	Whether the proof deserves approval

“Check completed” and “approved” should be separate states. An export tool can flag missing information without pretending to judge an artwork.

Studio process photograph supplied by Whispart. It illustrates material inspection; it does not identify a particular GAN release or document a controlled print comparison.

Close the loop with the physical object

The Whispart journal's account of physical proofing distinguishes room visualizations from physical evidence. That distinction is especially useful when a website makes an artwork look complete before it has been printed.

Attach the inspected proof to the exact file version, intended size, material and date. Record a concrete observation—such as a distracting edge or lost separation in a dark area—and the next action. If the file changes, do not silently carry the old approval forward.

For a practice that authorizes one physical release of a selected image, the decision to release deserves its own record. A successful export is an input to that decision.

Published by Whispart. This article was drafted and checked by an AI assistant using the studio's public documentation. Numerical examples are illustrative; no specific printer, color accuracy or durability result is claimed.

Designing a contact sheet for GAN art review

Whispart Studio — Wed, 09 Sep 2026 04:19:15 +0000

A gallery of generated images has two different jobs: letting someone see the range of a model, and helping them decide which candidates deserve a closer look. A beautiful grid can do the first while quietly making the second harder.

This note comes from Whispart, a studio developing and curating GAN-based images for physical artworks. Our published process separates generated candidates from selected images and finished releases. The interface below is a design proposal based on that distinction, not a claim that Whispart has deployed a particular review application.

Preserve the comparison before adding a score

Begin with a stable contact sheet. Give each candidate a persistent identifier, preserve its complete composition, and keep the initial order recoverable. Avoid a masonry layout for the primary comparison: a tall tile occupies more screen space than a square one, which can influence what receives attention.

Equal-sized containers are useful, but equal-sized crops are a different decision. Use object-fit: contain for the review thumbnail so that the interface does not silently remove an edge or a figure. A detail crop can be a separate, clearly labeled view.

Let the reviewer toggle between three views:

View	Question it supports	Limitation
Complete contact sheet	Is there meaningful variation across this batch?	Small details are difficult to judge.
Single candidate, complete image	Does the composition hold together without its neighbors?	One image cannot demonstrate the range of a system.
Detail at a stated zoom	Is that mark deliberate-looking ambiguity or a distracting artifact?	Enlarged detail cannot decide the whole composition.

A high-resolution image should load when requested; the initial sheet can use smaller derivatives. Keep the same candidate identifier attached to both. A thumbnail and its full-size file must never drift apart because filenames were sorted differently.

Make “undecided” a real state

An unchecked image has not necessarily been rejected. A reviewer may not have reached it, may need a larger view, or may be postponing a decision until a series becomes clearer.

For a small tool, an illustrative record could look like this:

{
  "candidate_id": "study-017",
  "review_state": "hold",
  "observation": "The pale area competes with the figure at thumbnail size.",
  "next_check": "Inspect the complete image on its own.",
  "reviewed_at": "2026-09-09T04:00:00Z"
}

This is fictional example data. Its useful feature is the separation of observation from action. “Bad image” does not tell the next reviewer what to inspect. A bounded visual observation does.

Keep unreviewed, hold, shortlisted, and excluded distinct. Store a change history if multiple people can alter a decision. Shortlisting should not automatically authorize printing or publication; those are later decisions with different evidence.

Keep the studio's preferences legible

Whispart's approach values emotional tension, ambiguity and images that continue to hold attention. A default “sharpness” score would therefore be a poor substitute for the studio's judgment. Blur may matter to the image; a technically clean output may still be uninteresting.

For another practice, graphic clarity might be essential. The interface should let the reviewer state that preference instead of smuggling it into a universal quality number. Notes about visual structure, repetition and unresolved questions are more useful here than an unexplained score out of ten.

The Whispart process journal provides the concrete workflow behind this proposal: a visual field becomes candidates, then human selection, writing and material proofing determine what can become a physical work. A contact sheet supports the selection stage. It cannot supply all of the later decisions.

Published by Whispart. This article was drafted and checked by an AI assistant using Whispart's public studio documentation. The interface and example record are proposals, not reported production software or research results.

A seed is not a provenance record: documenting generative art outputs

Whispart Studio — Tue, 08 Sep 2026 04:03:35 +0000

A seed is useful when you want to revisit a generated image. It is much less useful when someone asks which checkpoint produced the image, whether the displayed file was cropped, or which candidate eventually became a physical work.

Those questions need a small chain of records: run → output → selected image → production file → physical proof. You can keep that chain in JSON files and a folder of evidence before you need a database.

This article proposes a lightweight record format for people building generative art workflows. The example is fictional and is not an export of Whispart's internal production system.

Give the run and the image different identities

Treat a run as the configuration used to generate a set of candidates. Give each candidate its own identity, even if it shares a seed with an image from an earlier experiment.

For the run, preserve:

The exact checkpoint file, with a checksum to identify its bytes.
The generation code revision and resolved configuration, including default values.
The software environment and relevant hardware information.
A dataset version reference, when you control the training process, with its source-review records stored separately.

For each output, record the run ID, sampling inputs and the actual exported file. Depending on the implementation, sampling inputs can include a seed, a saved latent vector, conditioning inputs or additional noise settings. Record what the particular generator consumes; don't assume a seed captures all of it.

Even a carefully recorded configuration is not a promise of identical pixels everywhere. PyTorch's reproducibility documentation explains that results can differ across releases, platforms and CPU/GPU execution. Keeping the original output file gives you a reference when a later rerun differs.

Record what happened after generation

Suppose a fictional studio selects candidate-0042, crops it for presentation and later exports a separate file for printing. If all three images are called final.png, the history becomes difficult to reconstruct.

Instead, preserve the original candidate and record each derived file with its parent and the operation performed. A crop changes the boundary of an image; an upscale changes its pixel dimensions. Neither operation should silently replace the original record.

Selection is a separate event. Record which candidate was selected, by whom, when, and why. A short, specific note is more useful than a generic quality score: for example, "Keep the uncropped image for review; the narrow crop removes the secondary figure."

This separation matters when generated images become physical objects. Whispart's illustrated GAN process distinguishes a model, an output, a selected image and an authorized physical release. It also distinguishes presentation mockups from physical proofing evidence. The record format below applies that distinction to file management; it does not imply that the studio uses this particular schema.

A small example you can adapt

The following is an illustrative record with unresolved fields, not a completed production record. Paths and IDs are invented. Replace them with actual files and computed checksums before relying on the record.

{
  "schema_version": 1,
  "example_only": true,
  "run": {
    "id": "demo-run-01",
    "checkpoint_file": "models/demo-checkpoint.pkl",
    "checkpoint_sha256": null,
    "code_revision": null,
    "configuration_file": "runs/demo-run-01/config.json",
    "environment_file": "runs/demo-run-01/environment.txt",
    "dataset_version": null
  },
  "output": {
    "id": "candidate-0042",
    "run_id": "demo-run-01",
    "seed": 42,
    "sampling_inputs_file": "runs/demo-run-01/inputs-0042.json",
    "file": "outputs/candidate-0042.png",
    "sha256": null
  },
  "presentation": {
    "id": "presentation-0042-a",
    "parent_output_id": "candidate-0042",
    "operation": "crop",
    "file": "presentations/candidate-0042-crop.png",
    "sha256": null
  },
  "selection": {
    "status": "pending",
    "selected_asset_id": null,
    "reviewer": null,
    "reviewed_at": null,
    "reason": null
  },
  "production": {
    "source_asset_id": null,
    "print_file": null,
    "print_file_sha256": null,
    "proof_photo": null,
    "proof_result": "not_reviewed",
    "release_id": null
  }
}

Notice that the presentation crop exists while selection is still pending. Making a mockup does not automatically approve that crop for production.

Here is a concrete way to use the example:

Compare the original output with the presentation crop. If the original is selected, set selected_asset_id to candidate-0042; if the crop is selected, use presentation-0042-a. Save the reviewer, time and actual reason.
Export the print file from the selected asset. Record that asset's ID as production.source_asset_id, and compute the checksum of the exported print file.
When a physical proof is made, attach a photograph of that specific proof and record the review result. If it fails, preserve the failed attempt and create a new production attempt rather than overwriting it.
Assign a release ID only when the studio's release decision is complete. Keep any edition policy in a separate, explicit record.

A room visualization can help you assess scale, but it belongs with presentation material. It cannot fill the missing proof_photo field.

Check the relationships before you trust the record

Start with a few checks that catch ordinary mistakes:

Does every referenced file exist, and does its current checksum match the saved value?
Does each derived asset point to the actual parent used to create it?
Does the production file trace back to the selected asset?
Does the proof evidence identify the same production attempt?
Are unresolved fields still visibly unresolved?

A checksum helps detect a changed file. It does not establish who created it, whether a source was appropriate to use, or when an event occurred. Keep source-review notes and dated decision records alongside the files, with version history or another audit trail appropriate to your needs.

If you retain only one thing from an exploratory session, keep the actual output and its run reference together. That makes the next decision—regenerate, compare, select or prepare for print—possible without reconstructing the session from memory.

Published by Whispart Studio. This article was generated by an AI agent using the linked source material. The example schema is proposed guidance, not a claim about a deployed studio system.