Keep interface evidence untouched: a separate palette brief for community illustrations

Disclosure: these are project-side notes from LUT Generator, not an independent review, a Karura integration, or an endorsement by this community. The documentation scenario below is hypothetical. No wallet connection, governance action, investment claim, or measured product result is part of this note.

Two pictures with different responsibilities

A community explainer might place a photograph beside a screenshot of a technical interface. They can look like a single visual composition while carrying very different responsibilities. The photograph establishes atmosphere; the screenshot records what an interface actually displayed. A shared palette can make the layout feel coherent, but that does not make the same editing treatment appropriate for both pictures. Decide what each image is allowed to communicate before choosing a color adjustment.

For a hypothetical documentation header, imagine an original photograph of a notebook and a desk lamp beside an untouched interface capture. A warmer version of the desk photograph could be a reasonable illustration choice. Applying that treatment to status colors in the capture could change their meaning. The illustration should be reviewed for appearance; the capture should remain accurate evidence, with any necessary annotations clearly separated from its pixels.

Name the evidence boundary first

Put a plain sentence in the image brief: illustrative photographs may receive color adjustments, while interface evidence remains unchanged. If a screenshot needs a highlight, add a labeled annotation on a separate copy and retain the original. Never use color matching to make a warning resemble a success state or to imply a transaction, vote, or deployment that did not occur. Decorative consistency is subordinate to the information the image must preserve.

This boundary also helps contributors who were absent from the initial discussion. A folder containing several attractive exports does not reveal which file is an illustration and which is evidence. Names such as source-photo, illustrative-preview, interface-original, and annotated-copy make that distinction easier to retain. They are workflow labels, not assurances about authenticity; the underlying source and its context still matter.

Describe a reference without claiming authority

Choose a reference image that you own or have permission to use. Write down the limited feature you want to explore: quieter greens, warmer paper, or a gentler contrast between a bright window and a desk. A reference is an aesthetic direction, not a certification of accurate color. It also does not authorize copying someone else's artwork or presenting another creator's photograph as your source.

Keep the reference separate from organizational branding and interface semantics. A warm photograph cannot establish what a protocol's official colors should be. If a guide needs a canonical logo or a state indicator, use the relevant official asset and current documentation rather than inferring it from an unrelated picture. This note is about a small illustration workflow, not a method for redesigning or validating a governance interface.

Match only the photograph you intend to edit

LUT Generator works with a source photo or SDR video frame and a reference image, then allows color adjustments and reusable .cube export. The project is available at https://ailutgenerator.online/. Its matching, manual adjustments, and PNG preview are free; custom .cube export uses credits. That distinction matters when a contributor only needs an illustration preview and another contributor is considering a reusable transform.

A useful first pass is deliberately small. Choose one representative source photograph, keep an unchanged copy, and make one comparison against the reference. Do not feed an entire documentation archive into an aesthetic experiment. A candidate that seems promising on a desk scene may still affect another photograph poorly. Treat the first preview as a question for review, not as proof that every image in a collection should receive the same look.

Give reviewers specific things to inspect

Ask a reviewer to look at the paper, the lamp shade, and the shadow under the notebook separately. Does the paper retain visible texture? Does the warm lamp become an undifferentiated bright patch? Are the shadows readable without drawing attention away from the document? These questions are more actionable than asking whether the picture looks professional. They also make disagreement easier to describe without pretending that an aesthetic preference is an objective performance measure.

Check the photograph at the size used in the article, not only in a large editor window. A small header may lose details that appeared clear in a full-size preview. That is a layout observation rather than a benchmark of the tool. Keep any conclusions local to the image, display, and page arrangement actually reviewed. If nobody has opened the intended layout, record that review as still outstanding.

Keep the screenshot out of the experiment

Compare the interface capture against its original independently of the photograph. Check that text remains legible, status colors retain their meaning, and labels do not imply a result that the guide has not established. If the screenshot contains private information, create an explicitly redacted derivative and document the redaction rather than replacing important text with plausible invented data. Color grading is not a privacy process or a substitute for checking what the image reveals.

An accompanying caption can state that the photograph is illustrative and the capture is contextual documentation. Avoid implying a live connection between the color tool and the interface. No Karura integration, automatic screenshot validation, transaction verification, or official partnership is claimed here. The useful connection is editorial: contributors can preserve evidence while giving separately editable illustrations a consistent, carefully bounded visual direction.

Distinguish a preview from a reusable transform

A PNG preview is a particular image result. A .cube file is a color transform intended for reuse, and its usefulness depends on the material and the receiving workflow. Do not rename a preview as a preset or describe the existence of an exported file as proof of compatibility. An SDR reference-based adjustment is also not a camera-profile conversion or a promise about HDR handling.

If a contributor needs a reusable transform, inspect it in the intended receiving application with representative material before making a broader claim. This note does not report such a test. The honest handoff can simply say that a candidate export exists and downstream review remains pending. A modest statement with a named limitation is more useful than a confident claim that another contributor cannot reproduce or verify.

Explain optional assistance and data handling

The optional AI assistant can suggest color adjustments. It uses a reduced-size preview, while export validation sends a color table. Do not describe the entire workflow as wholly local or imply that no data leaves the browser. Contributors should make their own decision about whether an image is suitable for the optional assistance path, particularly when it contains unpublished work, identifiable people, private notes, or other sensitive material.

For a simple illustration, manual review may be sufficient. If optional assistance is used, preserve the distinction between a suggested adjustment and an accepted editorial choice. A suggestion does not establish technical accuracy, consent, copyright clearance, or suitability for publication. Those responsibilities remain with the contributor and the actual review process, regardless of how convenient an editing interface feels.

Hand over the decision, not just a file

A compact handoff should identify the source photograph, permitted reference, selected preview, and whether a reusable export was actually requested. Add one sentence about what improved and one about what still needs checking. Keep the unchanged interface capture and any clearly labeled annotated derivative separate. This record need not become a complicated approval system; its purpose is to prevent the next person from guessing why several similar files exist.

The final editorial question is straightforward: does each image still tell the truth about its role? An illustration can be an openly chosen interpretation. Evidence should retain the facts it is being used to show. Keeping those roles separate lets a documentation team discuss color without turning a decorative preference into an unsupported technical, financial, or community claim.