Feature request: Timeline view

[helmut72]

Please add a Timeline view option from current folder and all sub-folders. A Timeline view like in common Photo Apps (iOS, Samsung Gallery).

/
-/folder1
--/subfolder1
---/subsub1
--/subfolder2
---/subsub1
-/folder2
--/subfolder1
---/subsub1
--/subfolder2
---/subsub1

Eg. when in root ("/"), from folder*/subfolder*/subsub* and when in /folder1, from /folder1/subfolder*/subsub*

Thank you!

[bpatrik]

Hi,

Do you mean, when you are in a folder, you wold like to see all photos in that folder and in all subfolder?

[helmut72]

Yes and sorted by date. Just like the typical photo gallery apps in smartphones. Would be great to have a header that group at least by week and month.

Have a look at the left screenshot:

[bpatrik]

I see.
In (a distant) future I might add advanced search see #58 where you can limit the time frame, and optionally save those searches a virtual folders (see #45), but I do not plan to implement an all-in photos view at the moment.
The idea behind the app is that the user have a well organized photo structure and have an app that you point to the root folder and presents those photos online. I can recommend piwigo or leeche. Those apps probably have these features.

[ghost]

Limiting the time frame during searching is very useful, but I think timeline view can also be helpful when you have a very large folder with thousands of photos in it.

Timeline view doesn't necessarily require advanced search or flattening the folder structure. It can alternatively be added to every folder as dividers between groups of photos taken within a period of time.

Say if you sort a folder by time, and enable timeline view that divides the photos stream by one month. That would greatly accelerate the browsing compared to guessing the current month by typing every possible range in the advanced search box.

[bpatrik]

I think @helmut72 was reffering to flattening the whole directory and having an all in timeline view.
Actually I would like to have that, but that requires a major refactor on both the server and client side. Now if you download more than 2k photos the side just cannot handle it. I added a setting to app so people may play around the hardcoded 2k search limit and see capability of the current page. (i.e: see what happens if someone wants to show their photos at one screen)

Within one folder it should be easier to implement a timeline view. Would you be interested implementing something like this?
It would require creating a view like the current grid: https://github.com/bpatrik/pigallery2/tree/master/src/frontend/app/ui/gallery/grid

And based on a setting (similar to the directory sorting:

pigallery2/src/frontend/app/ui/gallery/gallery.service.ts

Line 20 in ee355dd

public sorting: BehaviorSubject<SortingMethods>;

)
the gallery should use the grid or the timeline view here:

pigallery2/src/frontend/app/ui/gallery/gallery.component.html

Line 38 in ee355dd

<app-gallery-grid [media]="_galleryService.content.value.directory.media"

to render photos

[helmut72]

I think @helmut72 was reffering to flattening the whole directory and having an all in timeline view.

Yes. "... and all subfolders" ;)

Usually I have 3 ways to find my photos.

1. Timeline view. Like on the iPhone (or iPad) Photo App from Apple. There should be also a date on the top.

2. Album (=Folder) view. Nothing to say, this feature is there

3. From location. Nothing more to say, it's also there.

[garritfra]

From location. Nothing more to say, it's also there.

Did you mean a full map view with all pictures? Because I cannot find that in the root directory.

[bpatrik]

So you can kinda trigger this today too by searching for something common, like "." : https://pigallery2.herokuapp.com/search/%7B%22type%22:100,%22text%22:%22.%22%7D .
This will basically list all your photos/videos that you have. The issue is that above a few thousand photos, it kinda breaks (or rather your browser gets extremely slow) and fixing that is not trivial.

[bpatrik]

I wrote a blogish post about the gallery in: #292

I mention this feature there too. This is the relevant part:

---

Feature: Basically show all the photos at once, grouped by data and the scrollbar shows the dates while you scroll. Basically what the famous big photo galleries can do. (do not expect to get implemented in full extend this year)

• Technically it is possible to do something similar even today (searching for something like .), but in big galleries (50k+ photos) both the backend and fronted will be slow.
  • On the backend one bottleneck that all photo info that goes back to to client contains if thumbnail exist for that photo (does a HDD read, for 50k+ photos, 2-3 thumbnails sizes, that is a lot of fileExist check)
  • Rending all 50k+ photos on the page at once would trigger 50k+ http image download from the server. (RPi would just go kaboom from this :/). So some load prioritization is needed here. -> needs to be implemented.
    Furthermore, not sure, how a browser would behave If the app wants to show 50k+ photos on one html page.
  • Timeline view only make sense if pigallery could detect filesystem changes on its own (without navigating there in the app). Otherwise, people add new photos to the gallery but that wont show up in the timeline view. They would scratch their head and open tickets on github :)
• I can imagen a partial solution, where the app can automatically detect the changes but only shows the last X (=~5k) photos. That would serve most of the use-cases, (like you open the app and sees all new photos), but the app would still be able to handle it.

[TAW-V]

Maybe dividing the photo timeline over multiple html pages. With each page a certain month.

Might that be a solution?

[bpatrik]

No, pagination is sooo 2010. :)
Also with pagination what photos would be part of the map.
As its a timeline view I would want to see all my photos, but If I only have one page worth of photos at client, I cannot show all on the maop

I think latest X photos would work. The feature would be called, latest photos instead of timeline, so noone should have too high expectation. X could be set from config. The brave onces can set it to 999999999 which would result to a timeline view. The rest can wait while the necessary improvements are done.

[bpatrik]

It is blocked by: #299

SQL queries are not fast enough to support massive queries that this feature would require.

[kagahd]

So you can kinda trigger this today too by searching for something common, like "." : https://pigallery2.herokuapp.com/search/%7B%22type%22:100,%22text%22:%22.%22%7D .
This will basically list all your photos/videos that you have. The issue is that above a few thousand photos, it kinda breaks

It breaks because it searches from root and not from the current folder. If it searched from the current folder, as described also in the feature request, the result set would be smaller and #299 wouldn't be a blocker anymore.
If somebody really wanted to flatten folders from root or from a folder that contains multiple thousands of photos, then he/she would see "only" the first hundreds of photos, as it's the case today already how PiGallery2 handles queries returning too many results.

I'd like to extend the feature request: instead of sorting by time, it should be sorted by what the user has selected, means by name, date (ascending or descending) or random.

[bpatrik]

1. flattening from non root

Search should work in a way now that if you search for a directory with not exact match then it lists all media in a given directory and in subdirectories.

Relevant part from #284 (comment):

exact match: directory:"the directory"
any match: directory:(the directory)
any match: directory:(all images/some dir/the directory) <-- flattening the "the directory", assuming this is the full path

If it does not work, please report a bug.

2. Capping search results

Lately I increased the default value of the max returned media item / search result to 10K b4e831c

According to my experience on a RPi4 searching for a person with 5k photos takes ~3s, while searching for . ~61k photos takes ~30s. (I set the max media/search value to 100k on my home setup)

3. Improve SQL performance #299 block

I was not really considering adding flattening directories from a given directory, but only from root. I haven't really seen any use-case about it at other mainstream apps. (I want to keep the app easy to use, 'mom' safe. I want all the features to be straightforward or if complicated, hidden in menus)

I was only considering support timeline view from root, with its dedicated tab on the top bar. I'm also thinking eventually making it the default view. When I usually open the app I want to see the photos from our latest events. A default timeline view would make it possible and fast.
The blocker on #299 comes in that currently it takes 30s to load the full gallery for me with 61k photos.

4. sorting

I plan to implement the timeline view just as a search result look like, with all sorting (or filtering feature #287)

[bpatrik]

Gave some more though to it.

I think we can add a flatten button to the navbar (next to the sort button) that would be a shortcut a directory search that would eventually flatten the gallery from a given directory.

Pro:

• its a simple change
• if you do it on the root dir, you get a full timeline view
• does not hurt anyone (smaller and more hidden feature than like a full time line view tab)

Con:

• higher up you do the slower it will be
  • Improving search will also improve this feature (one codebase on the backend)

There is one catch. Wont work on the following directory structure:

• a/b/c/1.jpg
• subdir/a/b/c/2.jpg
  searching for directory:(a) will list both 1.jpg and 2.jpg (no way to avoid that)

It can be solved with: #313

---

I think in a distant future the app should still support a full timeline view as being the default tab to open up, with <1s load time, showing 50k+ photos, but that will take a while.

[bpatrik]

Added a button to flatten directories. It wont work for in all use-cases, see #313, but for the most of them its ok.
You need to explicitly enable it in the settings. Default value is disabled. Look for enableDirectoryFlattening or Directory flattening to enable this feature.

[bpatrik]

I'm adding a new config where you can customize the navbar buttons.
The aim would be to create a Fresh button that would list the latest photos (it would be just a search in the background).
The Fresh button won't be added by default as it would need the app the auto detect if new photos are added but the search does not trigger reindexing.
You can manually enable in the config.json

Sample config:

<....>
 "NavBar": {
<....>
                                "links": [
                                        {
                                                "type": "search",
                                                "name": "Fresh",
                                                "SearchQuery": {
                                                        "type": 10,
                                                        "value": 1640995200000
                                                }
                                        },
                                        {
                                                "type": "gallery"
                                        },
                                        {
                                                "type": "albums"
                                        },
                                        {
                                                "type": "faces"
                                        },
                                        {
                                                "type": "url",
                                                "name": "github",
                                                "SearchQuery": null,
                                                "url": "https://github.com/bpatrik/pigallery2"
                                        }
                                ]
                        },

It will result in:

There is no way to set it through the UI at the moment as it is experimental.

[bpatrik]

The reasoning behind the Fresh button is that the app cannot (and wont in the near future) support large listings (5k+) in reasonable time. Most of the time ppl only watch the latest photos, so this Fresh button is good compromise.

[bpatrik]

Now you can add the Fresh button in the settings:

Result:

[helmut72]

Thanks for this feature. Need to think about if there is an usage. It's not a usual timeline view.

Most of the time ppl only watch the latest photos

If someone need to click down to (sub)folder to view a moment, you may right. But especially a timeline view bring people to watch photos from the past regulary. At least what I saw from family and friends. We watch a moment (eg. vacation), talk about it, remembering other moments and scroll down to the other vacation.

Having a timeline view not only from the root folder (/) but from subfolders too (eg. /vacation, /daily, /party), would show us just vacations, but not other unrelated or even unwanted ;) photos for this talk...

But anyway, if it's impossible with pigallery2 you can close this feature request.

[bpatrik]

If someone need to click down to (sub)folder to view a moment, you may right. But especially a timeline view bring people to watch photos from the past regulary. At least what I saw from family and friends. We watch a moment (eg. vacation), talk about it, remembering other moments and scroll down to the other vacation.

Having a timeline view not only from the root folder (/) but from subfolders too (eg. /vacation, /daily, /party), would show us just vacations, but not other unrelated or even unwanted ;) photos for this talk...

That should be already possible:
You need to enable it as it is by default disable:

Then a button shows up:

But anyway, if it's impossible with pigallery2 you can close this feature request.

Unfortunately it would take a major refactoring to enable this feature. Like rewriting the whole serving and caching part. The app does not support any pagination or partial loading. That would break the map and the local filtering.

Closing this sounds good to me.

[helmut72]

Thanks for clarify. Will try it soon. Thanks for at least this feature!