Geektoolkit/Dynaframe3

Controlling what's displayed with metadata?

Closed this issue · 18 comments

Organizing photos has always been a challenge. Do we use folders? And if we do, how do we organize the files? In the old days, it was folders. Now, it's tags.

I use Lightroom Classic to organize, catalog, tag, and manipulate my master photo library. There was a time when it became clear that it didn't matter at all which folder my photos were stored in as long as I tagged them with keywords in Lightroom.

If Dynaframe relies on photos being found in an actual folder then the level of automation that can be achieved is reduced significantly as there's much more manual manipulation of file locations and even duplication of files.

Lightroom doesn't like it when we move or alter files outside of Lightroom. It breaks the connection.

So, as an example, if I wanted Dynaframe to display a set of photos based upon some sort of criteria, I would want to be able to pass the right URL from NodeRED in Home Assistant such that only the photos that fit that URL parameter will actually show.

Let's say it's our 5 year wedding anniversary. I want my Dynaframes to cycle through all of our wedding photos, but the wedding photos are buried in multiple folders...however, they're ALL tagged as "Our Wedding" so I can quickly catalog and reference them in Lightroom.

It is possible to create photo sets in Lightroom and then copy them to a new location which would be readable by Dynaframe, but that jumps right back into the problem of file duplication, and a bit more maintenance than the Home Assistant enthusiast is going for.

How difficult would it be to incorporate a way to select photo sets based upon more than just their folder location? Information like date ranges, tags, naming conventions, etc?

long answer below, but TLDR: The pi has limited memory, but I'll investigate this and try to do it, it's a great idea.

Long/background version:

I see what you're saying, and I'll have to think on it. One of the biggest constraints with anything related to this project is honestly the Raspberry pi...everything I implement has to be done in such a way as to try to keep memory usage down, and fileIO/processing as low as possible. Getting a file list from a specified folder is fairly quick...even with a hundred images. Things are constrained by the folder name, and so the search pattern and actual processing is straightforward.

To do things with tags would involve scanning every photo for tags, and then either keeping that mapping or adding a database to store it (but then also requiring a refresh periodically).

That being said, there is no denying the power and utility of being able to do slideshows based on tags vs folders. When I started this project it was very much thought of as a 'high touch to ensure a quality experience'. So the concept of throwing 1000 photos at it...I frowned upon that. I'd rather have had the user filter the photos down to the best 20 or so, including cropping them for the frame resolution and such to make sure that the exprience is great (because photos that weren't the correct resolution/size look terrible if there are black bars...it destroys the digital frame camouflage that I intend this to be)

That being said, I've been investigating approaches like ken burns, we now have scaling added, and as the projects grown in popularity it's being increasingly used as a photo slideshow system and less as a digital poster system. With the ability to add NAS/rcloned drives it's starting to look at more files that it ever has. And the home automation stuff I've built in to control it makes it inviting to get into home automation, but as you point out, limited.

I have a few features I need to wrap up (I'm working on rotation detection and almost have it working, as well as I need to make the logs easier to get a hold of for debugging). Once I have those I'll put this on the backlog and investigate it. I have the code to pull exif tags, so I may have the begining of this. I'll try to see if I can serialize a database to a file to handle performance, and maybe take a hit on load, or try to do a background task to update that file. Maybe I'm grossly overestimating how long it'll take to scan say 1000 files worth of metadata.

I'll look into this. thankyou for the well written idea and justification for it. I can see this becoming very useful, I just have to see if it can be done, but I won't know that till I try :)

Ooh...I just thought of something else.

This may be a bit ridiculous, but what if I were to create 1080p images of a custom designed clock...all 720 of them, to show what would appear to be a digital clock or analog clock on one screen.

Would it be possible to not only switch the image every 60 seconds, but ensure that it was at the top of the minute, and not just by a 60 second interval, and synchronized with the correct picture of the clock?

Update: Lightroom does in fact write tags to the exif data on the file. It creates "Keywords: tag1, tag2, tag3" etc. and "Subject" and "Heirarchichal Subject" all with the same data.

I wonder if there's a way to use exiftool to scan every file in a folder and output some sort of json to create an index of sorts...I'll let it lie at this point. Love the app so far.

In a case where the file database exceeds 1000 units stop consistently reindexing with each file change. Make it only do this every 2 hours or so. 10000 images, then every 8 hours or so.

then an option to choose folders or tags in the settings and then a multi-column list of tags detected on the playlist screen. If it's in tags mode make it a 15 min min refresh. and 2 hours over 1k and 8hrs after 10k.

just scale the pi's need to index, once you have a playlist of tags, and a masterdatabase of filenames to tags, building the playlist isn't that hard, it can be a database saved in numerical order, and then the internal plalist is just an advancing number instead of a long filename.

I also think parsing the metadata into a file would let you choose other fields like author to be easy to display, or use as a playlist enumerator.

while i think that dynaframe will adopt some of this in the future in the meantime you could build your clock idea as below.

@arretx
you can send screen on and off html commands, the pi's would stay on tho. you can also point all the screens at the same file directory and turn sync on which would cause all screens to show the same photo. you can technically tell the screen what file to choose, so a quick node red script could immediately acomplish your clock1301.jpg at exactly 13:01pm. it would look something vaguely like....and my code sucks, but then you've set your home automation to send a photo on each time change.
start
192.168.1.1 > pause (http://192.168.1.1:8000/default.htm?COMMAND=CONTROL_PAUSE_On)
192.168.1.2 > pause
192.168.1.3 > pause

loop
time = get from clock HHMM
if time = lasttime then wait
else
http://192.168.1.1:8000?SETFILE=/home/pi/Pictures/clock%time%jpg
http://192.168.1.2:8000?SETFILE=/home/pi/Pictures/clock%time%.jpg
http://192.168.1.3:8000?SETFILE=/home/pi/Pictures/clock%time%.jpg
lasttime=time
loop repeat
end

I just talked about this on another unrelated project, but it occurs to me that there is more or less a standard out there for playlist management, perhaps looking at a way to create that database to conform to .kpl or really any versitile PML, and implement it via an existing opensource library. perhaps you can shoot a lot of the issues, and offload that development burden to people that specialize in playlists.

https://en.wikipedia.org/wiki/Playlist_markup_language

also I can confirm that other than long initial load times i can start a frame on a library of over 100,000 photos and it seems to run and randomize fine. The loading time looks a bit like a crash though, since there is no blank screen at first index. a built in black photo to run immediately after the base initialization just before the playlist generation would confirm that dynaframe is running and doing what is expected, as well as solving part of the startup issue mentioned elsewhere about streamlining in a way that makes the software more kiosk friendly.

Thanks @qwksilver for that, I've made notes and will look into it. I'm glad to hear your'e pulling 100k files and thats working...the perceived perfomance fix of having a starting image should be doable and a small fix.

@arretx I want you to know that your ideas sparked numerous discussions between myself and friends and members here. Qwksilver has had some great ideas which he mentioned above, and after thinking about it I do want to do something along the lines of supporting exif data. the trick, as usual with this project is to be careful about resources since it's running on a pi. (if this was a windows app...I'd have implemented it that day :) The pi just makes things tricky, and we're already maxing out some of it's capabilities).

For the three screens, you should be able to load from the same folder and sync them up. The sync engine needs work, and is one of the items that should get some attention soon.

The clock scenario...I think that'd work, you'd want to use scripting like Qwk suggested to really get it 'in sync'. having proper network sync'd time is on the backlog to improve syncing, and could improve that. I'm trying to think if there's a better way to do that though.

In the end let me say...I hear you, and will do what I can for what makes sense. Having tag support is a much better way to manage playlists for those that have their files tagged, so I'll see what I can do.

I'm perpetually plagued with the problem of coming up with a way to make things better, and it usually means causing the system that's already in place to fail because I try to make it do what it appears it can, but can't quite do yet. My headstone should say something like "what if we could do.......this..."

The clock idea is doable. I didn't even think to consider that the timing of the image change could easily be handled by NodeRED in Home Assistant.

In 1997, I was the operations manager at a computer hardware distributor. One of the most controversial discussions we had was over how to organize the hard drives. Do we group them first by brand, or by size? Speed, or interface? It was a nightmare, because the software only allowed categories and sub-categories, like folders and sub-folders. It made searching a nightmare. Years later I learned about Gmail and the way emails are tagged. It's taken me even until this past year, when I started using Lightroom Classic, to realize that it doesn't matter if all of my media files are in one folder anymore, because of tags. ;).

The whole project is a great idea regardless of its current iteration. I am having a strange problem, however. On the Pi3+, I've mounted a folder to a remote SMB share and made that the playlist source. When the Pi3 re-boots, it fires up Dynaframe, and shortly thereafter appears to crash...only it's not crashing. It's still running, but I see the Pi3 desktop. Periodically, one of two *.MOV files in that folder begin playing, full-screen, for a moment, and then disappear back to the Pi3 desktop. I'm not sure why the files in the SMB shared folder structure aren't being displayed. shrug. Not sure how to troubleshoot it.

LOL, as an engineer I get and appreciate the 'what if it could do this' aspect. And if I didn't ask that, I woudl've installed someone's simple image solution and never made Dynaframe. But I HAD to have videos. And it needed a webUI. And playlists. and syncing. And...and...and...now here we are. :)

For the issue you're seeing, I suspect it's due to moving a mouse. If you have a mouse plugged in, try not to move it. It crashes the UI and causes what you're seeing. I'm pretty sure this is due to the software I'm using to hide the mouse not playing well with Avalonia, and we've tried some fixes, but it plauges us. The thing is...dynaframe is still running, jsut the UI is gone, so to get out of that state you have to do something like: sudo pkill Dynaframe and then restart it (./Dynaframe) from the Dynaframe folder...or you should be able to reboot.

Please let me knwo if that's it. The mouse bug has been a plauge, but if you unplug it should be ok. (or try not to move it...if your using VNC I just start it and close the window)

For playing videos all the day through there is a PR in for it but I want to add it as optional so some more work to do. I don't want to force that change on everyone because everyone has different needs for how they want that behavior to work.

For stability, the pi3 needs to use a lot more Processing to pull off the transitions causing it to heat up and eventually thermal throttle or just lock up. If you have a transition time of 10 seconds and then 2-3 minutes between transitions it should run slow enough to give it time between images to slow down I believe. Pi4 though just behaves better.

@arretx So now that i have blurboxing in (a feature that's plauged me for a while, and has some new issues I'll have to deal with..but later) I've been taking a look at exif data. I don't have lightroom..when I tag a file it adds it to exif but it's some 'xp metadata' thing that Windows does (even on windows 10). Can you please email me a few sample files with tags to joefarro at hotmail dot com with tags in place...I'd like to see where the tags end up with lightroom classic and compare. I think I have a cool way to implement this without doing a full rewrite of things.

My plan is to use the existing folder structure to get the initial image list, and then have an optional setting for 'filter by tags'. You'd then give a list of tags, and if any of the tags are found for each file, the file stays in the list. Since this would only happen at 'list generation' it'd be a one time perf hit per playlist...and if the playlist is huge then you'd not see a hit until it was reindexing. If the playlist is small it'll just go quickly regardless.

Anyway, my main features before next release are this, the video playback option, and a way to delete a file when it's shown. Then I'll work to do a release and work towards stabilizing it, do the usual video/release cadence and then work on the next things.

2.22 is up with initial Exif support. It is still a beta release and needs stability and performance fixes but it may get you something to play with.

Closing as this feature is in, and post 2.23 will be released to all.

Sure I'm at joefarro at hotmail.com.