A local CSV ledger for comparing photo edits
A local CSV ledger for this workflow
The workbook below can be supported by a small local CSV ledger. The example code validates column names and variant identifiers, then prints a concise summary; it does not inspect photographs, upload files, judge visual quality, or integrate with any service. The six standard-library tests were run locally and passed; that is a narrow check, not a security audit or a production guarantee.
Adapted from the project’s Photo Look Comparison Workbook; AI assisted the original and this adaptation. This is a project-associated resource, not an independent review.
This workbook is a practical, tool-independent way to review two edits of the same photograph. It helps a creator separate a change in crop from a change in color, record permission and audience decisions, and explain why an image was selected. It is intended for creative and educational use. It is not a technical inspection method, evidence of image authenticity, or a substitute for an editor's judgment.
The examples are hypothetical. They are prompts for a review, not results of a study. You can copy the worksheet sections into a local document, a paper notebook, or a project management tool; no account or command-line installation is required. Keep the record with the project rather than posting photographs or private information in a public issue.
Disclosure and an optional tool
I am associated with Y2K Photo Lab, and AI assistance helped prepare this workbook. One optional tool for trying an early-digital appearance is the https://y2kphotoeditor.online/. It runs in a browser and offers looks, strength adjustments, comparison with the original and cropping. Studio adds more detailed controls, custom stamps, larger exports and batch editing. Check the official site for current features, terms and pricing. This mention is not an independent product test and is not a claim that all features are free.
You do not need to use that tool. The same comparison can be carried out with another editor or with manually prepared images. The point is to record what changed and why, not to make a particular preset the correct answer.
- Set a purpose for the image
Before opening an editor, write down the intended format and audience. A picture for a small profile may need a simple background and a clear face; a wide editorial illustration may need context around the subject. The same crop can be successful in one place and confusing in another. Avoid using “make it look better” as the only objective because it does not tell a reviewer what to check.
Fill in these prompts:
Intended use: Where will the image appear, and for how long?
Audience: Who is expected to see it, and is the space public or private?
Essential content: What must remain visible or understandable?
Constraints: Is there a required aspect ratio, caption, size or deadline?
Decision owner: Who can approve the final version?
If the answer to any question changes later, note the change. A version that worked in a private presentation may not be appropriate as a public thumbnail. A second review is useful when the audience expands or when an image is reused for a new purpose.
- Preserve the original and check permission
Keep the source file unchanged. Work from a copy and use a naming scheme that distinguishes the original from the edits, for example original, version-a, and version-b. Include a short note about where the source came from and whether the people or organizations represented in it have granted the necessary permission. Do not assume that a picture found online is available for reuse.
If the image contains a person who has not agreed to a public post, choose a different source or obtain permission before publishing. If a project uses client material, follow the agreement governing that material. For a practice exercise, use your own photograph, a deliberately staged image, or a properly licensed source. Keep sensitive contact information out of the workbook unless it is actually needed for the handoff.
The record is not legal advice. It is a reminder to ask the right questions before a file leaves the project. When rights are uncertain, resolve them with the appropriate person rather than asking an image editor or a text generator to decide.
- Choose a baseline and two variants
Pick a baseline crop first. Then make two versions that differ in one principal respect. For example, keep the crop fixed and compare a restrained warm treatment with a stronger warm treatment. If one version also changes orientation, contrast and framing, a reviewer cannot easily identify which change drove the preference.
A comparison does not have to be perfectly controlled to be useful, but the record should be honest about what varies. When several settings change together, label the result a combined treatment rather than claiming that a single adjustment caused the response. Save the settings if the editor makes that possible, or write down the visible controls and the approximate choices you made.
Prepare the session by recording the crop, main colour change, texture, contrast, export dimensions and notes for each version.
Do not invent numbers for controls that were not measured. If a slider has no displayed value, a plain-language note such as “low grain” is more honest than a fabricated percentage. Record the date and software version only when you know them.
- Review at more than one size
Look at all three files at the size in which they will actually be used. Then inspect them at a larger size for unintended artifacts. A texture that is attractive on a large screen may compete with a face in a small square. Conversely, an apparently subtle crop can remove a piece of context that matters in a full-width image.
Use the same viewing conditions as far as practical. Put the files side by side or switch between them without changing zoom. If you can, repeat the check on another display, but do not claim color accuracy simply because two screens look similar. Record the display and viewing conditions if the decision depends on fine color differences.
Separate observations from preferences. “The sign is difficult to read at the target size” can be checked by another viewer. “The warmer image feels more welcoming” is a preference that may differ across people. Both are legitimate; labeling them makes the review more useful and avoids turning taste into a false measurement.
- Use a neutral review sheet
Ask reviewers the same questions before showing them the creator's preferred version. Offer a “neither” option and invite a short explanation. A suggested set of prompts follows:
What did you notice first in each version?
Is the intended subject recognizable at the target size?
Has the crop removed something needed to understand the image?
Does texture or grain obscure a detail that matters?
Which version suits the stated audience, and why?
What single change would make the chosen version easier to use?
Keep the answers proportionate to the decision. A social profile picture does not require a formal research process. If several reviewers disagree, document the reason for the final choice instead of presenting the number of votes as proof that an image is objectively superior. A minority comment about privacy or a missing detail may be more important than a majority preference for color.
- Check context and captions
An old-camera effect can imply that a new picture is an archive. Where dates matter, keep the true capture date and explain that the appearance was edited. Do not use decorative effects to imply a historical event, endorsement, or result that did not occur. Check names, places and credits independently before publishing a caption.
For scientific, medical, legal, architectural or other consequential records, the requirements may be stricter. Preserve original files, follow the applicable integrity rules, and do not use a decorative edit as the sole basis for a technical conclusion. If the image documents a condition, ask a qualified person what processing is permitted. This workbook does not provide domain-specific validation.
- Create a handoff that another person can understand
When you finish, keep a short decision record alongside the selected output:
Source file and permission status.
Intended use, audience and dimensions.
Selected version and the reason for selecting it.
Major changes, including crop, color and texture.
Known limitations or unresolved questions.
The location of the untouched original.
Avoid storing passwords, private links or unrelated personal information in a public repository. If a colleague needs access to an original file, use an approved private transfer method and confirm that they received the correct version. A good handoff tells the next person what to do if the image needs another crop or a new audience changes the requirements.
- Run a final, reversible check
Before sharing, compare the chosen export with the source one more time. Confirm that the file opens, the intended crop is present, the caption is accurate, and the people shown are comfortable with the planned use. Revisit the permission decision if the destination has changed. If a problem appears, return to the preserved original rather than repeatedly editing a compressed export.
A short checklist is valuable because it makes creative judgment visible without pretending to automate it. The creator remains responsible for the final image, the permissions, and the context in which viewers encounter it.
Example: a local-only Python ledger
Save the following as photo_review_ledger.py, then provide a UTF-8 CSV with variant, crop, treatment, intended_use, and observation columns. The example rejects duplicate variant labels case-insensitively and rows with extra fields. Keep the CSV private when its descriptions contain personal information; the script does not protect it.
"""Validate and summarize a small, local-only photo review CSV."""
import argparse
import csv
from pathlib import Path
FIELDS = ("variant", "crop", "treatment", "intended_use", "observation")
def read_rows(path):
with Path(path).open(encoding="utf-8-sig", newline="") as source:
reader = csv.DictReader(source)
missing = set(FIELDS) - set(reader.fieldnames or ())
if missing:
raise ValueError("Missing columns: " + ", ".join(sorted(missing)))
rows = []
seen = set()
for number, row in enumerate(reader, start=2):
if None in row:
raise ValueError(f"Row {number}: too many fields")
item = {key: (row.get(key) or "").strip() for key in FIELDS}
if not any(item.values()):
continue
if not item["variant"]:
raise ValueError(f"Row {number}: variant is required")
identity = item["variant"].casefold()
if identity in seen:
raise ValueError(f"Row {number}: duplicate variant")
seen.add(identity)
rows.append(item)
return rows
def summary(rows):
lines = [f"Variants: {len(rows)}"]
for row in rows:
notes = row["observation"] or "(no observation recorded)"
lines.append(f"- {row['variant']}: {notes}")
return "\n".join(lines)
def main():
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("csv_file", help="local UTF-8 CSV review ledger")
args = parser.parse_args()
try:
print(summary(read_rows(args.csv_file)))
except (OSError, csv.Error, ValueError) as exc:
parser.exit(2, f"Cannot read ledger: {exc}\n")
if __name__ == "__main__":
main()
Run python3 photo_review_ledger.py review.csv to print the local summary. This example is intentionally small: add file-permission controls, input limits, validation, and application-specific tests before adopting it in a production process.
All rights reserved
