Add option to output albums as branches #31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds a .yml option: photos_as_resource_pages
If set to true, default behaviour will be changed to produce
- a directory `name` for the album instead of one `name.md` file
- an `_index.md` for the album inside this directory
- a `name.md` for every photo inside the same directory
Key properties of the photos will be saved in the front matter.
This change provides the basis for users who want to use keywords
to generate automatic collections of pages using Hugo's taxonomy
and have more finetuned control over the data being used to generate
the album.
To optimally use this new functionality, the user will need to
deploy new list templates that repicate the {{< wrap >}} and
produce the desired output.
Adds a .yml option: generate_branch_bundle
If set to true, default behaviour will be changed to produce
- directory `name` for the album instead of one `name.md` file
- `_index.md` for the album inside this directory
- `name.md` for every photo inside the same directory
Key properties of the photos will be saved in the front matter.
This change provides the basis for users who want to use keywords
to generate automatic collections of pages using Hugo's taxonomy
and have more finetuned control over the data being used to generate
the album.
To optimally use this new functionality, the user will need to
deploy new list templates that repicate the {{< wrap >}} and
produce the desired output.
|
This is my first time collaborating on a code project so definitely open for suggestions and feedback. My goal with this feature is primarily to be able to leverage EXIF tags and Hugo's taxonomy pages. It may be possible to do that with the feature in #24 but I prefer actual pages as they are much easier to edit. I'd call the current feature usable for advanced users. With a bit of template magic I was already able to customize my website where the list template looks for a tag "cover" in the photo pages and, if unavailable, falls back to the first photo in the set. Ultimately this feature, especially if coupled with EXIF tag extraction (future development) would allow to push photos from a photo manager to the source gallery, run hps, run hugo and have a re-indexed photo website without any editing of YML files in between. My intent is to add EXIF reading functionality to dump that into the front matter as a future pull request. To not make matters overly complicated I developed this as much as possible as a separate feature. In #24 I noted that you were looking for documentation and tests before adding to master. I've added documentation of this feature but don't know what tests you'd be looking for. I couldn't identify any relevant tests in the current code base. |
Use PIL's TAGS to deal with EXIF. Use iptcinfo3 to deal with IPTC tags. Allows to use these as fallback options for copyright and caption of photos. As a sample use-case also implements the fallback for the photo album to be determined from the set of photos in it. Will not change the default behaviour without adding the setting tag_map, exif or iptc to the configuration file.
Returns None instead of raising AttributeError when accessing a setting that is not defined.
Remove unused imports Add iptcinfo3 to the project requirements Tidy up some wording
# Conflicts: # docs/README.md # hugophotoswipe/album.py
Do not overwrite the hps.yml config file after every run. hps new: quit bitching about existing folders. Now specifically checks if the album.yml file already exists instead of the folder itself. _load_albums: Look for nested albums Switch default logging level to INFO and verbose to DEBUG. Replace print() with logging.INFO/WARNING in hps.py Include level & function in logging message Reduce verbosity of _load_albums
Merged
Photo() returning an object even if the file has been removed.
Photo() returning an object even if the file has been removed. We moved this test to album.update() with a try clause so that the album.photos will only ever return actual photos. Updated the _load_albums() to call new() album when setting enabled and the album doesn't exist yet.
- Remove exif based copyright from album.py. It unnecessarily complicated matters. - Remove memory leak in calling PIL.Image.open() by encapsulating in a with block.
number of simultaneous open files.
Use PIL's TAGS to deal with EXIF. Use iptcinfo3 to deal with IPTC tags. Allows to use these as fallback options for copyright and caption of photos. Will not change the default behaviour without specifying the setting tag_map, exif or iptc to the configuration file.
Ignores local changes (photo_exif & branches) but realignes with upstream improvements.
Catch-up to master
Use PIL's TAGS to deal with EXIF. Use iptcinfo3 to deal with IPTC tags. Allows to use these as fallback options for copyright and caption of photos. Will not change the default behaviour without specifying the setting tag_map, exif or iptc to the configuration file.
Also add test cases for improperly formatted tags.
Need a more robust solution to extract arbitrary attributes. For now, removing this from this branch.
iptcinfo spews many warnings about missing IPTC data, reading before image or decoding error. Most of the time this just seems to mean that the desired tags aren't present.
# Conflicts: # docs/README.md # hugophotoswipe/photo.py # tests/test_photo.py
Adds a .yml option: generate_branch_bundle
If set to true, default behaviour will be changed to produce
- directory `name` for the album instead of one `name.md` file
- `_index.md` for the album inside this directory
- `name.md` for every photo inside the same directory
Key properties of the photos will be saved in the front matter.
This change provides the basis for users who want to use keywords
to generate automatic collections of pages using Hugo's taxonomy
and have more finetuned control over the data being used to generate
the album.
To optimally use this new functionality, the user will need to
deploy new list templates that repicate the {{< wrap >}} and
produce the desired output.
(cherry picked from commit be88345)
Note: Was not detected in test suite because all test images have exif['Orientation'] = None.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a .yml option: generate_branch_bundle
If set to true, default behaviour will be changed to produce
namefor the album instead of onename.mdfile_index.mdfor the album inside this directoryname.mdfor every photo inside the same directoryKey properties of the photos will be saved in the front matter.
This change provides the basis for users who want to use keywords
to generate automatic collections of pages using Hugo's taxonomy
and have more finetuned control over the data being used to generate
the album.
To optimally use this new functionality, the user will need to
deploy new list templates and possibly add more detail to the
individual photo files. Commit adds minimal documentation to
use the functionality.