MQTT topics and messages

[paddywwoof]

I will put these comments in a new discussion to make them easier to reference (hopefully this has now settled down and won't change too much):
00. There are two styles of topic depending on how communication is being used by homeassistant. In the list below I will give the topic followed by possible messages. First switch or button style, then value messages

0. on the basis that you have defined device_id: 'picframe' in configuration.yaml
1. display on/off: homeassistant/switch/picframe_display/set, ON,OFF
2. paused on/off: homeassistant/switch/picframe_paused/set, ON,OFF
3. shuffle on/off: homeassistant/switch/picframe_shuffle/set, ON,OFF
4. back: homeassistant/switch/picframe_back/set, ON
5. next: homeassistant/switch/picframe_next/set, ON
6. name text on/off: homeassistant/switch/picframe_name_toggle/set, ON,OFF
7. date text on/off: homeassistant/switch/picframe_date_toggle/set, ON,OFF
8. location text on/off: homeassistant/switch/picframe_location_toggle/set, ON,OFF
9. directory text on/off: homeassistant/switch/picframe_directory_toggle/set, ON,OFF
10. title text on/off: homeassistant/switch/picframe_title_toggle/set, ON,OFF
11. caption text on/off: homeassistant/switch/picframe_caption_toggle/set, ON,OFF
12. all text off: homeassistant/switch/picframe_text_off/set, ON # yes that is confusing!
13. text refresh: homeassistant/switch/picframe_text_refresh/set, ON
14. delete: homeassistant/switch/picframe_delete/set, ON

values:

1. directory: picframe/directory, string matching directory name
2. date_from: picframe/date_from, string YYYY/MM/DD or number representing unix timestamp or zero length string to remove constraint
3. date_to: picframe/date_to, string YYYY/MM/DD or number as above
4. fade_time: picframe/fade_time, number
5. time_delay: picframe/time_delay, number
6. brightness: picframe/brightness, float 0.0 to 1.0
7. location_filter: picframe/location_filter, string matching any part of geolocation description
8. tags_filter: picframe/tags_filter, string matching tags
9. stop: picframe/stop, message not used - just stops

[helgeerbe]

I have to check, but I think

• date_from: picframe/date_from, float timestamp
• date_to: picframe/date_to, float timestamp

[paddywwoof]

Yes obviously there is an increase in compression so there must be a loss in quality. However for 95% of photographs the difference is imperceptible... for the the other 5% that have large areas of almost the same colour the drop in quality to 75% does sometimes produce visible compression artifacts! As it doesn't seem possible to find the quality level the image was originally saved at this process is probably fraught with danger as you say.

I also can't really see why you would have pictures that were rotated but didn't have exif info. Maybe they are are slides that have been scanned, but why would you want to use the picture frame as a photo editor when it's trivially easy to run them through any number of image editors (or most viewers that come with OS) and correct the orientation.

So we should explicitly exclude image editing from the scope of picture_frame but it still might be relevant to store info back onto the db at some stage.

Paddy

[helgeerbe]

Absolute! My family asked, if it might be possible to do the image paring only with images, that have related colors. Or to do the pairing selection manual on the browser interface. Some of my images don't have a title. For a little tweak it would be nice, to change that on the fly. But you have to be aware, that the info is lost, if you drop the database. So have in mind. If we start this, we have to deal with updates and backups. Because, the database is then not a simple cache any more.

[paddywwoof]

I suppose the colour could be calculated using the function used in the mat_image file but it's a non-trivial exercise to find the optimal pairing of nearest points in 3D space - it wouldn't have to be very accurate, but even so I suspect at least O(n²). However the initial entry onto the db is done without a full load of the pixels as would be needed to determine the representative colour. At the moment the mat colour is based on only the left image, as is the text etc - that's probably a more urgent, and also quite hard, problem to fix. In the short term we should probably just make a note of these things and mop them up later (the github issue system is actually very good for this: assigning priority, responsibility etc)

I've also just pushed a final (famous last words!) fix of a very annoying bug cause by L or 1 mode images with the mat calculation and rectangle drawing. Took ages to track down - I had to remove the try: except: blocks in order to see details of the errors and even then it was far from clear.

Next job is probably to do some installs on RPi3 and RPi4 clean SD cards and see what we've forgotten.

Paddy

[jgodfrey]

At the moment the mat colour is based on only the left image, as is the text etc - that's probably a more urgent, and also quite hard, problem to fix.

When I did the image color selection initially, I considered combining all (1 or 2) images together before making the color selection. While that'd be trivial to do, I'm not sure whether it'd make (visual) sense in the end. That said, I never tried it.

Regarding the text overlay info. I've been meaning to ask about that. Really, we have all of the info for both images, and it should be trivial to access it. I guess the bigger issue is in how / where to display it for this case. I have a small-format digital frame here that's able to present portrait pairs. With the text overlay on, it simply presents 2 lines of text (top line is left image, bottom line is right image). Alternatively, maybe we could present the text on 2 halves of the screen, to sort of mimic the image layout. Minimally, I'd guess the text would need to be smaller than (the default) is today. Is there other issues here too that I've missed?

In the short term we should probably just make a note of these things and mop them up later (the github issue system is actually very good for this: assigning priority, responsibility etc)

Yep. I agree.

I've also just pushed a final (famous last words!) fix of a very annoying bug cause by L or 1 mode images with the mat calculation and rectangle drawing. Took ages to track down - I had to remove the try: except: blocks in order to see details of the errors and even then it was far from clear.

Good find. I haven't tested with any grayscale images. Though, I will say that having all of the errors gobbled up by try/except blocks was driving me crazy too during some of my work. That's why I added the raise that's currently at the bottom of tex_load(). In my case, that was enough for me to see what was happening...

Next job is probably to do some installs on RPi3 and RPi4 clean SD cards and see what we've forgotten.

Yeah, that'd be great. I'm about to order a few more RPi4's. Until then, I only have one.

Somewhat related... I'd like to check out your http work, but haven't even begun to look into it. Is there a set of instructions buried in a thread somewhere that might help me get started?

[paddywwoof]

Jeff, I suppose the alternatives for the text are a) keep one full width text block and append the info for the second image below the first (maybe with a LEFT: and RIGHT: b) have two text blocks and make the character wrap width half as big. Obviously both approaches would need extra code to determine if it was a pair showing in order to generate the second chunk of text. More tedious to do than difficult.

There probably is something in one of the threads about setting up http. It should just work if you set the config use_http: True and make sure the path leads to directory where the files were copied. If you browse to 192.168.0.987:9000 (whatever the RPi IP is and whatever port number you use) then it should serve the index.html page. There is also a user option 192.168.0.987:9000/current_image that will render whatever is showing on the screen to your browser.

You shouldn't need to send GET arguments directly as the js does that for you but for reference: The Controller methods that have @Setter decorators can be called by ?brightness=0.5 but the other methods need to have the arguments passed as json of kwargs i.e. next={} or ```set_show_text={"txt_key":"name", "val"="ON"}

As an exercise I should write this up and put it into Helge's wiki!

[jgodfrey]

Jeff, that seems good and is probably going to be sufficient. Looking at the code for blur_edges it does a similar thing with the diff_aspect (but calls it wh_rat!) and only attempts to do the blurring if it's out by more than 1%.

Regarding the above discussion about aspect ratio comparison and auto-matting images that are off by more than some defined percentage... We should agree on a method to calculate the difference between 2 aspect ratios as our methods currently differ.

In the case where the image and the screen aspect both match, our methods agree on that. However, when they don't match, the resulting values are (sometimes considerably) different.

I'm not sure there's any "standard" way to calculate such a difference (since it's 2D data represented by a single scalar value) - and probably it doesn't matter too much, but they should definitely be the same.

Any thoughts on which is better, or if there's a better way than either of the existing methods?

[paddywwoof]

Yes, I've not really thought about it, and +/- 1% won't matter, probably. Logically we're interested in the proportion of area that would be left either top and bottom or either side so that simplifies to

if disp_aspect > image_aspect:
    edge_proportion = 1 - image_aspect / disp_aspect
else:
    edge_proportion = 1 - disp_aspect / image_aspect

[helgeerbe]

Copy it to the wiki https://github.com/helgeerbe/picframe/wiki/Control-Interfaces