A picture full of data

A piculum is an ordinary PNG image that is also a container. You look at it and see a picture. Someone with the right password opens the same file in a piculum decoder and gets content back out of it: a message, a filled-in record, a file. The picture is real, the content is real, and they travel together in one file that behaves like any other image.

Read the white paper npm install piculum

The real power: you design the data, others fill it

A piculum is a designed object, and the design has two deliberately separated sides. What the designer builds is, in plain terms, a data dictionary that happens to wear a picture. If you have ever defined a database table and then generated entry forms and reports from the definition, you already know this shape.

Design

The designer decides what it is

Paint the regions, declare what each holds: a date, a name, a phone number, a choice from a fixed list, free text, a file. Each field gets a caption, a place, and a measured capacity.

Fill

The data person just sees a form

A date picker for the date, a proper phone field for the phone, a dropdown for the choice. They fill it in, and out comes a PNG. That PNG is the record.

Read

The reader gets the record back

Decode the PNG with the password and the record comes out laid out field by field, captions and all. Not a blob of text to interpret: the structured thing the designer defined.

Design once, fill many times, read anywhere. The tool is exactly that, a tool, not a service: encoding and decoding run locally, there is no server holding your records, no account to create, and nothing the file phones home to.

What that looks like in practice

An emergency-info card. Design it once: name, date of birth, allergies, medications, emergency contact. Fill one per family member. Each card is a photo on a phone that decodes, with the family password, into labeled fields a stranger could act on.
Business paperwork. A registration form, a warranty claim, an inspection record. The business designs the piculum; customers or field staff fill the form; the returned image decodes to a structured record every time, because the structure was designed in, not hoped for.
A software license badge. Each sale fills the form and issues the badge: a small image the customer keeps and presents when support or activation asks for it. A badge that was edited or forged fails at the vendor's decode instead of decoding to a doctored license.
A publisher with tiers. Regions carry their own passwords, so one designed image serves several audiences: the free password opens the hint, the subscriber password opens the solution.
A note in a photo. The undesigned case still works: encode a private message or a file into any picture and send it as a picture.

Why it holds up

It is just a PNG. As a picture it needs nothing: every image viewer displays it, everything that stores images stores it. As a container it needs the piculum software on both ends; the tool runs locally and free.
The protection is real. Each region is sealed independently with AES-256-GCM under a key stretched from your password (PBKDF2-SHA256, 100,000 iterations, fresh salt every time), all via the browser's built-in, audited WebCrypto. A wrong password or a tampered image does not produce plausible garbage: the seal refuses to open.
Access is layered by design. Per-region passwords are how piculums are built, not a bolt-on. One file, several audiences.
Capacity is honest. The designer sees, region by region, exactly how many bytes fit, while designing, before anything is filled.
The data can have a shape. Regions are painted, not boxed. A field's pixels can be a heart, a scatter of stars, or a precise-capacity blob dropped exactly where the designer clicks. The dictionary is also the art.

The one rule of care: a piculum's content lives in exact pixel values, so it survives anything that preserves the file, and does not survive being re-rendered. Screenshots and messengers that recompress images repaint the pixels and destroy the carried content. Send the file, not a picture of the file. And the password is the whole key: there is no recovery back door.

For developers

The template is a contract. The field definitions travel with the piculum itself, so a program using the piculum library can read a template, discover its fields and capacities, fill them, and emit the record, or take a record and consume it. The codec entry has zero dependencies and runs in browsers and Node; all encryption runs locally on the caller's machine.

npm install piculum pngjs   # pngjs only needed in Node

import { encodeMessage, decodePng } from 'piculum';
import { installNodePng } from 'piculum/node';

installNodePng(); // once, in Node; browsers need nothing

const { png } = await encodeMessage('hello', 'password', 200, 200);
const text = await decodePng(png.blob, 'password');

The codec never needs a key or an account - everything above runs entirely on the caller's machine. A hosted template registry (publish a design, fetch it by ID to fill) is planned as a separate, optional service; its API will require free API keys, which exist for quotas and abuse control, not billing.