con2 / edegal Goto Github PK

The use of the redirect_url field is not very consistent now:

• ✅Navigating to an album with a redirect_url to an internal path like /fooalbum will trigger an internal redirect in the frontend and open the referenced album instead
  • This was the original use case of redirect_url.
  • It should be used when you want to change the slug of an album without breaking links to said album: change the slug of the original album and create a hidden "redirect album" in its place.
• ⚠️Navigating to an album with a redirect_url to an off-site URL like https://kompassi.eu will probably barf.
• 🤔Viewing an album that has a subalbum with a redirect_url opens that URL in another window. As intended for external URLs, but internal paths here don't really make sense.

Split from #177.

Common album types for Conikuvat.fi include

• general event photos
• photos from a specific programme ("stage photography")
• cosplay studio photos, further divided into
  • open photo booth
  • competitor portraits

Design decisions:

• whether to make this a field in Album or a separate metadata model ("Conikuvat.fi metadata")
• whether to provide a fixed set of choices or make this open-ended and auto-completed

Make an album widget that can be embedded in a CMS such as Tracontent or Desusaitti. The widget should be able to load any single album from Edegal API and display its pictures embedded on a content page.

I think we shouldn't consider subalbums at first, or text content at all. After all, it would be rather yo-dawgy to embed a CMS inside a CMS.

Experiment with SSR to get faster first page load, better link metadata and improved search engine positioning.

The path field may never contain a trailing slash. If there is one in the URL, such as https://beta.conikuvat.fi/yukicon-4-0/, remove it.

Google Drive is a popular method of delivering pictures. It would be cool to be able to import directly from Google Drive without doing a zip–download–upload cycle.

The name Edegal originates in the year 2007, when Japsu wrote static HTML picture gallery generator called Egal (TL;NOTE egal is German for indifferent or forgettable) and then SpComb re-used the HTML/CSS and wrote Degal.

The joke was to add a letter in front every time a major re-write or new version occurs. The longest name discussed at that time was acedegal. Luckily we never got that far.

(As a side note, a character named Cedegal Eltenbridge appeared in 2010 in an Exalted pen-and-paper RPG one-shot at the Excalibur club at TUT. They got their first name from this project and last name from a company called L10Nbridge.)

So far the only serious suggestion for a new name has been Showroom. It can be abbreviated to shroom, meaning mushroom, which inspire a quirky mascot and/or logo.

Originals can be huge (like, 20 MB huge). For many use cases the preview image would be more than sufficient.

Change the "Download Original" button to a dropdown that lets you choose the format to download.

Example:

Web page: https://conikuvat.fi/desucon-frostbite-2020/yleiskuvat/jenni-suominen/img-6106
Original: https://conikuvat.fi/media/pictures/desucon-frostbite-2020/yleiskuvat/jenni-suominen/img-6106.jpeg (4 MB)
Preview: https://conikuvat.fi/media/previews/desucon-frostbite-2020/yleiskuvat/jenni-suominen/img-6106.preview.jpeg (350 KB)

Have the Photographer as a separate entity in the database, possibly but not necessarily connected to a User.

This should be added at the album level and be propagated to pictures as well. Perhaps in the future make it possible to override the photographer at a per-image basis, but at the moment we mostly have single-photographer albums.

In order to not make this too easy, multiple Photographers may take part in the making of a picture and they may have differing roles. Actually we might have other kinds of artists as well, such as model, make-up, lighting etc. But let's handle the 95% case first and worry about complex cases later.

https://web.dev/native-lazy-loading

Demo of current state: https://larppikuvat.fi/danakar-rajahdysherkka/timeline

• Backend: Hoist original capture time from EXIF data to Picture table (taken_at)
• Backend: If URL ends in /timeline, output a timeline pseudoalbum
• Frontend: Have "Timeline" appear at the end of the breadcrumb (translated)

Timeline visualization

• Display an 1D heatmap visualization of the timeline, highlighting the times during which there are pictures
• Show hours as ticks on the timeline
• Highlight the currently displayed chunk of the timeline
• Allow quick scrolling by dragging the said chunk
• Show date and time somehow

Press FF to doubt.

• Lazy loading: Firefox does not support loading="lazy", so make up some JS fallback.
• Preloading: Our current approach of floating <img> tags created via JavaScript does not trigger pre-loading in FF.
• Alt texts visible in blue while loading thumbnails: Perhaps just make alt texts (link text) grey or sth.
• Make sure WebP is used on FF 65+: Last I checked, image quality was potato, which can be expected on JPEG but FF should support WebP nowadays. Make sure our WebP detector correctly detects Firefox as WebP capable.

After import, some pictures appear without taken_at causing pictures to be in wrong order.

python manage.py refresh_taken_at fixes this, so it is not a matter of not having EXIF creation dates on the files or not being able to read them.

This is probably a race condition of some sort within the media importer. Perhaps someone overwrites the picture model instance with taken_at unset?

A photographer wants to be featured at the site but does not want to upload their photos to the site. Instead, they want to host their photos at Flickr or some other external site.

• Figure a way to add these as "redirect albums" so that they show up in the listing but clicking them opens the album instead in a new window.
  • If an album has redirect_url, it's called a "link album".
  • If such an album is a visible subalbum of another album, it will be displayed with a redirect icon.
  • Selecting said subalbum will open the redirect_url in another browser window.
  • When adding a link album, one picture should be uploaded to it to give it a cover picture.
• When creating link albums that link to popular services (such as Flickr), a thumbnail image should be extracted automatically. Possible sources include service specific APIs and HTML <meta> values, such as <meta name="og:image">.
• The use of redirect_url is not consistent now. This should be fixed. See comment.

https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4

Pre-requisites:

• Unflagged AVIF support in browsers (Chrome 85, Firefox 87)
  • https://caniuse.com/#search=avif
• AVIF support in Pillow or similar straightforward Python encoding & metadata solution
  • python-pillow/Pillow#5201

Everyone is using Lightroom, right?

Wrong.

Lightroom by default renders RAW to the expected orientation, so these work fine with Edegal. Apparently in-camera JPEGs do not, however.

Currently there doesn't seem to be possibility to import lot of images. It should be possible to upload multiple files and/or upload a zip file containing photos.

Another way would be to upload the files to a selected directory on server.

Something like this is really needed. If it is possible, please mention it in the documentation. Otherwise this looks like really promising gallery software.

https://github.com/woltapp/blurhash

Current strategies:

1. Cover picture EXIF
2. Regex on description/title

Add a third one:

3. Parent album date if set

Unsure if this was EdgeHTML or Webkit.

Original description: "tossa vois olla face-detection joka ottaa neliöthumbit naamasta eikä navasta"

Currently thumbnails are always landscape despite the orientation of the actual picture. Portrait pictures are cropped at the middle.

It is somewhat difficult to pack pictures of different orientation and aspect ratio. Flickr has a good implementation in which the height of the rows varies.

We should respect the photographer's choice of crop and show the full picture in the thumbnail.

Add a similar feedback widget as Kompassi has on the lower right.

The exact same implementation is not directly applicable as Kompassi is a traditional web app and Edegal is an SPA, but the basic logic should be the same.

On the Conikuvat.fi site, top level albums usually represent one event. We should add the option for basic event meta data for event root albums:

• Event name
• Venue
• Starting and ending dates
• Event logo

These events are often managed using the Kompassi (GitHub project) event management system, and the basic event information should be imported from there. Perhaps just add a Kompassi event slug to an album and have other info automatically imported from Kompassi API (cached, of course).

Later we could support CSS customization by event etc.