visualdynamics.io.photo_files¶
photo_files
¶
Photos out as the pictures they are.
A Photos object holds the file bytes exactly as they arrived — that is
the point of storing them encoded rather than decoded — so writing them
back out is a copy, not a re-encode. A JPEG that goes through this comes
out the same JPEG, byte for byte, and loses no generation.
This writes a folder, which is the one place it is not simply the inverse of reading: a Photos object is ordered and named, and a folder is neither. The names survive as filenames; the order does not, and is recovered on the way back in only as far as the file manager's own sorting takes it. Nothing else about the object is lost — there is nothing else.
Functions:
| Name | Description |
|---|---|
file_name |
A filename for one photo: its own name, made safe, made unique. |
save |
Write every photo into the folder |
Classes¶
Functions:¶
file_name
¶
A filename for one photo: its own name, made safe, made unique.
Two photos may share a name inside the object — nothing stops it — and a folder cannot hold two files with one name, so the second gets a number rather than silently replacing the first.
Source code in src/visualdynamics/io/photo_files.py
save
¶
save(
photos: Photos,
path: str | PathLike,
unit_system: UnitSystem | None = None,
**_kwargs: Any,
) -> list[str]
Write every photo into the folder path, which is made if absent.
A folder rather than a file, because the object is several pictures and a picture format holds one. Returns the paths written, which is what a caller staging files for a drag needs.
unit_system is accepted and unused: a photograph has no units.