Support for descriptions and other metadata

[pmetras]

Hello,

I would like to be able to add long descriptions on the photos. Currently, the name of the file is used for the photo title but there's no way to add other type of information.

I suggest that one can add a TXT file alongside the photo file. When this file is present, MyPhotoShare can extract the information from that file. The information in that file must be tagged to be processed by the scanner (preferably) or the JavaScript. It can be used to put a long description of the picture, to prevent downloading or sharing an individual photo file, add watermark, etc.

[paolobenve]

Feel free to provide the code!

[pmetras]

Thinking of it, using a YAML (http://www.yaml.org/) file is probably more flexible to add other metadata. I'll look at Python YAML modules.

[pmetras]

Well, YAML is perhaps overkill for this simple need. I'll probably fall back to using good old INI file. There is no need for external module.

Instead of creating one file per picture, it's simpler to have a single myphotoshare.ini file per directory. Here is what it could look like:

# Additional metadata for album, pictures and videos
# See syntax on https://docs.python.org/3/library/configparser.html
# This is only a fake sample!

# These default values apply to all media content in the directory
[DEFAULT]
# Media files in this album can't be shared: don't display Facebook, Google+, etc. buttons
share = false
# Media files can't be downloaded: don't display the option
download = false
# Apply the watermark file on all media
watermark = true
watermark_file = /var/www/myphotoshare/watermark.jpg

[Media1.jpg]
description = "A long description of the media..."
# This picture can be downloaded: display the button
download = true
# Manual geotagging of the picture
# You can use https://www.latlong.net/, https://www.gps-coordinates.org/ or similar service to find places
longitude = -73.588014
latitude = 45.508873

[Media2.jpg]
# Use the following title instead of the file name "Media2".
title = A nice picture
description = Another long description of another media...
# Display the share button only for Facebook and Twitter
share = facebook, twitter

[Media3.mp4]
# For a value can flow on multiple lines when indented.
description = A description appearing on
  multiple lines is also accepted.
# An use a special watermark
watermark_file = /var/www/myphotoshare/watermark1.jpg

[Media4.jpg]
# Don't index this media
private = true

[Media5.mp4]
# Use "Sunny holidays" instead of "Media5" as video title
title = Sunny holidays
# Managing empty lines and text justification is not clear
# at the present time...
description = "Video of our trip in Afghanistan.

  Lots of mountains...
  Lost in the mountains..."

[Media6.jpg]
# Don't put watermark on this picture
watermark = false

Now I only have to look how to code it in the scanner... At least starting with title and description options. /play trombone

[paolobenve]

ok, perhaps it's better if it's named .myphotoshare.ini

[pmetras]

In the end, I've decided for the name album.ini. I think it's important for that file to be visible for the user. I see it as a way to overload or complement metadata information. For example, in my tests, my pictures are not geotagged in the EXIF. But I know the locations where I shoot them and I want to add this information in the album.ini file to locate them in MyPhotoShare.

The file allows adding metadata for the whole album, but not sub-albums, and all pictures it contains. Albums can be moved without requiring changes in the album.ini file.

[paolobenve]

ok, that's seems good :-)

[joachimtingvold]

I'd suggest to go with JSON, as the metadata-files we already have is of that format. My suggestion would be to do this hierarchically; you could have one JSON-file for the album, which would give those details to all the images in the album, but if you have a JSON-file for a specific picture, the content of that would override for that specific picture.

To avoid the browsers to load N .json-files for N pictures (more or less), you could have a simple parser (that you run manually after updating the metadata, or is part of the scanner) that combines all the album- and image- JSON-files into the JSON-file we already have (that has the metadata extracted from EXIF). This way you could also even override the EXIF-data gathered by the scanner if-need-be.

[pmetras]

@jallakim I decided on INI files because:

• They are user and text editor friendly, more than JSON or other types of files.
• They are read by the scanner only and don't require another external package (included in Python ConfigParser).
• The can be used to manage all photos of an album. No need for a file per picture as I had initially thought.
• They support default 2 levels inheritance, that fit very well with album + photo 2 levels.
• Cited just for completion but I don't know yet if it is useful: they support a limited macro expansion feature. So I think INI files are a really good fit for the intended use in MyPhotoShare...

I won't add any new JSON files generated by the scanner or read by JavaScript.

[pmetras]

I have some working code. I have to clean it a bit and complete tests before sharing it...

To do my tests, I've added support for 4 metadata:

• title: ability to define a caption for the photo, overloading the file name.
• description: a long text.
• longitude: for photos that are not geotagged.
• latitude: for photos that are not geotagged.

For the moment, I only consider metadata, that is information that is displayed in the bottom drawer window. Later we can talk about directives for the scanner (for instance, a noindex command to not index the album).

What metadata do you feel important to be supported in the album.ini file? It can be new metadata (like description) or existing ones that the user can easily change without changing the EXIF of the picture (like longitude and latitude). Do you want being able to overwrite geonames like place_name for instance?

I'll add a date metadata to overload the date in the EXIF.

I have planned to add a tag metadata to allow browsing or searching photos on different axis than date or location.

Any comments?

[paolobenve]

I think that exif date, latitude and longitude are better treated in the scanner, because in order to get the correct switch between folder, date and gps albums all the albums must be reviewed. Actually, the scanner can generate the date and gps albus only after scanning all the folders. In other words, managing exif date and gps data at javascript side will only be useful for showing them.

I think that any place_name directive should be at a root level, i.e. should interest all the photos, it's not logic to overwrite the location for some photo and not for others.

Very intersting the tag metadata you propose!

[pmetras]

@paolobenve , the metadata in the album.ini file is for the scanner only. It should not reach directly the JavaScript user interface. album.ini files are not copied to the cache folder.

The album.ini file syntax is flexible enough that we can support many interesting scenarios, with metadata values applying to all files or only on some files in the folder. I've even added metadata to the folder itself, not used at the present time.

I've found that's important to be able to overload the place_name value. I live in the border of a big city and the neighbor city is smaller. The pictures I take in my house are geotagged as located in "small city", probably because the latitude/longitude for the house is nearer from small city center than the big city center. I could change the latitude/longitude for the photos to point at the right city center, but it's more work than to overload the place_name for these photos. My photos albums are sorted by events, and I can have some photos from different places in a single album. But the album.ini syntax allows me to change the place_name for all photos or only to some photos.

[paolobenve]

my last commit adds a check on album.ini modification time against json file modification time, and considers json file invalid if album.ini is newer

I also removed the album.ini read on origin_album

[paolobenve]

@pmetras did github notify you the questions I added to the code of the pull request?

[pmetras]

@paolobenve I've just received the comments from GitHub.

1. Regarding using date instead of dateTime. This date information is only used for sorting the photos in the date virtual folders and displayed in the metadata window. It's simpler for the photo owner to type a simple date than to type a date-time where the time portion won't be used. So in order to not mislead him, I decided to use the term date instead of dateTime. And datetime.strfptime() creates a datetime object, so it does not change the time of the metadata. Because of that, I can't write generic code but I think that it's worth the ease of use.

2. Should [DEFAULT] apply to sub-albums? I did not thought about propagating metadata to other albums. In fact, I wanted the album to be self-content: the metadata and the behaviour of an album must not change when you move the album to another place in the album tree. If we allow the metadata to propagate down to the sub-album, that property does not hold. And the 2 level sections inheritance was a buit-in feature of INI files, a perfect fit for what I wanted to do. Thinking more on that, I don't think it's a good idea to propagate to sub-albums. It really depend on how you organize your album tree. You can't delete a metadata value. In a sub-album, if a metadata does not apply to your content, you don't have a way to prevent its value applied to the sub-album content. The only way is to give a new value to that metadata in the sub-album. But this behaviour can be enhanced. I wanted to look at the metadata first because I truly needed the description metadata. Because my photos are not geotagged, I added the latitude and longitude that fitted well and I know where the pictures were taken. And then when I had errors in the geonames, I added place_name and others... Next, I want to look at putting directives into the album.ini file. It would be really simple to replace the hidden files .myphotoshare.exclude.files and .myphotoshare.exclude.tree by options like noindex = true or noindextree = true in the album.ini, and depending on which section you place them, you can decide not to index a single photo, all the photos of the album including or not sub-albums. Another candidate would be to have a propagate = true directive that changes the behaviour of metadata to propagate to sub-album. That way, we can be both happy ;-)

3. Date-time metadata for albums. For the moment, the metadata for pictures are printed into the metadata drawer window, but I plan to be able to display them besides the pictures, and similarly for folders. Adding the date to albums allows to change the sort in the date virtual folder, independently of their content. For instance, if you have pictures for the New Year taken on December 31st and January 1st, you can want to consider them in the same date folder event even if they were taken in two different years. These are extreme cases but it adds flexibility to the album.ini file.

[paolobenve]

do we keeping this issue open or close it?

[pmetras]

@paolobenve You can close it to reduce the number of open issues. Whenever I look at displaying the title and description metadata, I'll open a new ticket and I'll reference this one to continue the discussion if needed.