A Better Capture Log for Kirlian Photography

A Kirlian photography archive becomes easier to use when every image carries a short, consistent record. I would build the log around three questions: what file is this, what context belongs with it and what happened between the supplied capture and the version on screen?
Give every record a stable identity
Start with an identifier that remains attached to the record wherever its files travel. A simple sequence such as KT-2026-0042 can serve as your archive key. The identifier should point to a log entry, rather than attempt to describe every detail in the filename.
Keep the original filename in a separate field. If a supplier delivers several files together, retain the delivery folder structure or record how it was reorganized. Add the date received, the source and the person responsible for the entry. This allows a future editor to distinguish an acquisition date from a capture date without reconstructing the history from memory.
Record context without inventing precision
The 1976 study by Pehek, Kyler and Faust reports that moisture can alter the appearance of corona photographs. Its abstract connects those changes with the recording conditions during exposure. Primary research, 1976.
For archive purposes, the useful response is to preserve the context supplied with an image. Ask for available capture notes and keep them beside the file. Distinguish documented information from a later observation or an educated guess. If the recording conditions were not provided, write unknown rather than filling a blank with a plausible value.
The log is an editorial record, not a recipe for operating apparatus. Work from existing files and information supplied through the equipment's documented workflow. You can improve an archive substantially without designing a new capture procedure.
Use a small set of dependable fields
Choose fields that you can maintain consistently. A starting template might contain:
- Archive ID: The stable key connecting files, notes and exports.
- Subject description: A plain description of the recorded object, using a controlled label where useful.
- Source: The supplier, collection or contributor from whom the file arrived.
- Dates: Capture date if documented, date received and date entered into the archive.
- System identification: The apparatus or software name and version exactly as provided.
- Supplied context: The capture notes and supporting documents accompanying the image.
- File inventory: Original filenames, formats, dimensions and locations.
- Permissions: The evidence supporting storage, editing and the intended use.
Add a notes field for uncertainty. A short explanation such as capture date supplied only to the month is more useful than a falsely precise calendar entry. Review the template after a small batch, then keep it stable enough for repeated use.
Make filenames readable, not encyclopedic
Use a predictable naming pattern for working copies and exports. For example, KT-2026-0042_master-received.tif, KT-2026-0042_edit-01.tif and KT-2026-0042_web-01.jpg clearly separate three roles. These are naming examples, not instructions to convert every source into those formats. Preserve the received format whenever possible.
Keep the relationship between versions in the log. An export should point back to its working file, which should point back to the supplied source. Avoid relying on folder position or a filename such as final-final to explain that chain. If an editor changes the naming convention, document the change rather than silently renaming the entire collection.
Write a processing history another editor can follow
For each derivative, record who created it, when, which application and version were used, and which source file was opened. List operations in order: crop, rotation, tonal adjustment, color treatment, annotation and export settings, where applicable. An unchanged copy deserves an explicit unchanged-copy entry too.
Separate an image adjustment from an interpretation. A note saying increased contrast describes an editing operation. A caption describing the picture's meaning belongs in another field with its author and review status. This separation lets someone reuse the image without accidentally inheriting an earlier editor's explanation.
Where your archive tools support it, retain a checksum for each preserved file and derivative. Treat it as a file-identity check, while keeping the descriptive record and permissions evidence alongside it. An identifier alone cannot explain how a picture was made or what use was authorized.
Compare images on a stated basis
Before preparing a comparison, decide what question the pair is meant to illustrate. You might compare two supplied outputs, two crops from one capture or an original with a presentation edit. State that relationship in the layout and caption.
Use consistent display sizing and record any adjustments made for the comparison. If one image arrives with a different or incomplete history, flag that difference. A visually balanced layout is an editorial choice; it does not establish that the source conditions matched. Let the log carry those distinctions so the caption can remain concise.
Close the loop when an image leaves the archive
Record the exported filename, destination, caption and review status when a picture enters a presentation or article. Link that use back to the archive ID. Keep a copy of the exact delivered version, rather than assuming it can always be recreated later.
For an earlier planning step, read the supplier-question checklist. For help organizing the explanation around an image, follow the two-pipeline guide, or return to KirlianTech.

