Replies: 8 comments 55 replies
-
|
Hi Jeff, That is a pretty cool idea especially for people who often have differently formatted photos! I just showed this to my wife and she likes it! (A good sign generally as to what is permitted in the living room). Generally, I think it is very useful giving users various options especially because Pi3D is such a capable software that can do all kinds of crazy stuff. It would be nice if someday that found its way into PictureFrame2021! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the input @sapnho - much appreciated. And, glad your wife likes it. Actually, that was my first test here also... ;^) |
Beta Was this translation helpful? Give feedback.
-
|
Actually, one other thought for the virtual mat: I had researched the possibility of mounting a (Philips style) Ambilight strip behind the frame to blend the frame with the background. Would it be possible, instead of a fixed color mat, to have an Ambilight style? |
Beta Was this translation helpful? Give feedback.
-
|
@sapnho - I'm not really familiar with tech, but after a quick look... It seems to project some sort of a blurred "extension" of the displayed video frame onto the back wall. Relating that to this topic, wouldn't that be similar to what the "blurred edges" feature does now in the software? That is, if the mat was created from a blurred version of the photo, and then the photo was floated on top as shown in my OP - is that close to what you'd expect? Or, maybe I'm missing something important? Interestingly, I've already considered using a blurred photo for the mat fill, but I just haven't gotten to it yet... |
Beta Was this translation helpful? Give feedback.
-
|
It's similar but still different. What Ambilight does extend the picture beyond the TV bezels. In our case, this would mean that the mat is filled with the colors at the edge of the image in a blurred way. So, only the edges are relevant. The PictureFrame "Blurred edges" is basically a blurred reflection of the entire image (or half). This would be an amazing feature. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think we're on the same page here... So, ignoring massive aspect-ratio mismatches between the image and the display (for sake of simplifying the conversation), it seems like something like this would be close:
That'd be exactly like the sample images I show, except the mat would be filled with a blurred version of the image - scaled just enough to fill the display. |
Beta Was this translation helpful? Give feedback.
-
|
These look really good. I did think about doing something like the mat when I started with the version I made before Christmas. My thought was to have the 'cardboard' sheet 'on top' with bevel edges. Easy to flip it either way. The ambi light would have to attenuate to black (or white or whatever) quite quickly to avoid having too much frame and not enough picture - but yes it could just a variation of the blurred edge system. Having the mat as a pi3d object might be nice as it could then gradually change shape and color - presumably the ones in your pics Jeff are constructed in PIL |
Beta Was this translation helpful? Give feedback.
-
|
@paddywwoof - Yeah, that makes sense. I think we're saying the same thing, with the addition of some fall off of the blurred (mat) image as it approaches the edges (I assume that's an alpha adjustment?)
Yeah, that'd be great. I haven't really attempted to muck around there yet as I figured it was somewhat volatile ATM. Though, as soon as you're ready (and have some installation hints), I'd like to have it as my base version here.
Looking forward to this if/when you have time! |
Beta Was this translation helpful? Give feedback.
-
Related, here's some info and sample results from an available Photoshop script: |
Beta Was this translation helpful? Give feedback.
-
|
Here's an outline. The frame is a mesh of 24 vertices, it needs two or three vertices for the internal points as there are different normal directions to give 'sharp' edges. import demo
import pi3d
import numpy as np
def make_buffer(w, h, wi, hi, t):
# these are half width of outside and inside of frame and the width of the bevel
new_buf = np.zeros((24,8))
w_signs = [-1,-1,1,1, -1,-1,1,1, -1,-1,-1,1,1,1,1,-1, -1,-1,-1,1,1,1,1,-1]
h_signs = [-1,1,1,-1, -1,1,1,-1, -1,1,1,1,1,-1,-1,-1, -1,1,1,1,1,-1,-1,-1]
d = 1.0 * t
new_buf[:,0] = [w] * 4 + [wi + t] * 12 + [wi] * 8
new_buf[:,0] *= w_signs
new_buf[:,1] = [h] * 4 + [hi + t] * 12 + [hi] * 8
new_buf[:,1] *= h_signs
new_buf[16:,2] = d
new_buf[:,3:6] = -1.0 # normals
factor = new_buf[:,0:2].max() - new_buf[:,0:2].min()
new_buf[:,6] = (new_buf[:,0] + w) / factor
new_buf[:,7] = (new_buf[:,1] + h) / factor
return new_buf
(wi, hi) = (350, 250)
th = 5
display = pi3d.Display.create()
(w, h) = (display.width * 0.5, display.height * 0.5)
camera = pi3d.Camera(is_3d=False)
shader = pi3d.Shader("uv_bump")
flatsh = pi3d.Shader("uv_flat")
light = pi3d.Light(lightpos=(1,-1,-0.5), lightamb=(0.6, 0.6,0.75))
bump_tex = pi3d.Texture("textures/11073-normal.jpg")
buf = make_buffer(w, h, wi, hi, th)
indices = ((0,1,5),(5,4,0), (1,2,6),(6,5,1), (2,3,7),(7,6,2), (3,0,4),(4,7,3),
(8,9,17),(17,16,8), (10,11,19),(19,18,10), (12,13,21),(21,20,12), (14,15,23),(23,22,14))
frame = pi3d.Shape(camera=camera, light=light, name="",
x=0.0, y=0.0, z=10.0, rx=0.0, ry=0.0, rz=0.0,
sx=1.0, sy=1.0, sz=1.0, cx=0.0, cy=0.0, cz=0.0)
frame.buf = [pi3d.Buffer(frame, buf[:,:3], buf[:,6:], indices)]
frame.set_draw_details(shader, [bump_tex, bump_tex], umult=8.0, vmult=8.0, bump_factor=0.001)
frame.set_material((0.7, 0.4, 0.0))
pic_tex = pi3d.Texture("textures/photosphere.jpg")
pic = pi3d.ImageSprite(pic_tex, flatsh, z=20.0, w=pic_tex.ix, h=pic_tex.iy)
key = pi3d.Keyboard()
while display.loop_running():
pic.draw()
frame.draw()
k = key.read()
ch = False
if k == 27:
break
elif k == ord('w') and hi < h - 50:
hi += 1
ch = True
elif k == ord('s') and hi > 50:
hi -= 1
ch = True
elif k == ord('a') and wi > 50:
wi -= 1
ch = True
elif k == ord('d') and wi < w - 50:
wi += 1
ch = True
if ch:
buf = make_buffer(w, h, wi, hi, th)
frame.buf[0].re_init(buf[:,0:3], buf[:,6:])and put a normal texture such as the following into Also there should be a transparent, alpha blend shadow (essentially same as the text background on the new version of PictureFrame) under the mat but in front of the picture. And, obviously a two window version would be possible with an additional 16 vertices! |
Beta Was this translation helpful? Give feedback.
-
|
@paddywwoof - thanks for the sample. That's definitely a good start. I'll try to find some time to experiment with it soon. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I discovered a 'bug' in the pi3d shaders. When using an orthographic camera (i.e. I will push a new release of pi3d master branch (and on pypi etc) later today - probably not worth trying the code until after that. Sorry. (I will also add the edge shadows and color selector to the above code.) |
Beta Was this translation helpful? Give feedback.
-
|
Still toying with generating an "automatically matted" image for the frame. Here's some samples (both singles and portrait pairs) from the variation I'm most pleased with ATM. Any thoughts?
|
Beta Was this translation helpful? Give feedback.
-
|
@paddywwoof - Correct, the trade-off here is that the maximum displayable image size is made smaller with each additional mat / border. I'll work on a few more options as well. Related, I wonder if it's time to think about a better way to control the configuration of the image presentation. From a user's perspective, it'd be nice to simply select a single presentation style from a list of options and not have to understand some of the underlying details. Right now, I think that configuration is a bit fiddley and the code to manage it a bit complex (for example, the I haven't given it much thought yet, but I'd think there would be a way to normalize the desired image presentation into a single, simple, (mostly?) flat list of choices. And, that'd likely make the code cleaner and might serve to reduce unnecessary calls to image loading and/or resizing... |
Beta Was this translation helpful? Give feedback.
-
|
So, I'm nearly done experimenting with this (mostly, figuring out how to get the visuals I wanted). With that out of the way, I'm in the process of cleaning up / refactoring the code and (maybe) adding a few more automatic matting types. I'll post some more results when I have them. With luck, maybe I'll have a PR ready for initial submission over the weekend.. |
Beta Was this translation helpful? Give feedback.
-
|
looking forward to seeing that. (Just raising a glass of one of our local beers to one of your photo themes! Maybe we will be able to go to pubs again in the summer..) |
Beta Was this translation helpful? Give feedback.
-
I'm really looking forward to that too (and the linked beer looks great). Among my many varying interests, I'm an avid home brewer and am very much into the craft beer scene. During the pandemic, I've been doing a lot of brewing which has left me with American Imperial Stout, Russian Imperial Stout, German Festbier, English Mild Ale, American Wheat, West Coast IPA, and Old Ale styles on hand - though most are getting low as I give much of it to friends. Time to buy more ingredients... :) |
Beta Was this translation helpful? Give feedback.
-
Looking back through the samples I posted above, that "biertent Festbier" image is one of my homebrew beer labels... :) |
Beta Was this translation helpful? Give feedback.
-
|
Still working through some details here, as well as trying to figure out what options are actually useful to expose to the caller. Currently, it's possible to specify:
I'm mostly pleased with the auto-color selection, though not 100% of the time. Also, it's a bit slow. I experimented with various ways of getting a suitable color, but have been most pleased using a K-means clustering algorithm. While the results are better than other methods, it's slow because it takes an iterative approach and continues to refine the solution until its either 1) stable or 2) reaches some maximum number of iterations. I'm currently running it on an 80px thumbnail of the image in question, but even at that, it can take a number of seconds. Ultimately, I'd like to stuff the selected color into the cache for future use, but for now - it's recalculated each time (assuming a color isn't specified). Below are some samples of some of the variations - all using the same set of images for better comparison. First, one of each (current) mat style, using a textured background and the auto-selected color.
Now, the same styles and auto-color selection, but with no mat texture.
Finally, the same styles, with no texture, and a caller-specified base color (not necessarily a good color):
One other likely miss right now... I'm building all of the mat "decorations" (bevels, shadows, etc) using pre-defined nine-patch images. While these are very efficient (just a few hundred bytes per image) and infinitely scalable linearly, they are "pre-baked". That is, the bevel width, shadow width, ... are predefined. I've designed them for display on an HD res monitor, but they'll likely need to be made larger for 4k displays. Unfortunately, that's not as simple as scaling the existing images on the fly, due to the nature of a ninepatch image. Likely, if any of this work holds water, we'll probably want to provide a few variations of these nine-patch files for other resolutions (which is pretty easy). I may also add some sort of "Polaroid" look as an additional style, but I don't have much more in mind. If anyone has something specific they'd like to see, let me know. Anyway, I guess that's all for now. I still hope to have some code to share over the weekend. |
Beta Was this translation helpful? Give feedback.
-
|
I moved the data folder within picframe. I think your *.png files resides at the old locations. Can't find them in Paddy's repro. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the heads-up @helgeerbe. Looks like Paddy took care of the PNG file locations in his develop branch. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I might have moved them on the local repo but overlooked pushing them back to remote - until just now! I've been running the frames (including the Polaroid) on this laptop for a while and they're great - just going to update the RPi picture frame and see how they look full size. |
Beta Was this translation helpful? Give feedback.
-
|
Jeff, I think I have convinced myself that the numpy system is significantly faster and produces the same centroids (apart from variation due to random starting points.) See below (on RPi3 for 100x100 resize). I will push the revised file up to my remote repo (commenting out rather than deleting previous method for now). best color 136,107,83 in 6.566s # this is generated by the python method
best color 150,121,96 in 0.091s # this is numpy, generally 50 to 100 times faster
[[ 51 38 29] ## these are the other two centroids from the numpy method
[200 209 214]]
--
best color 131,110,91 in 10.378s
best color 150,131,111 in 0.106s
[[ 50 32 25]
[210 202 192]]
--
best color 107,144,185 in 11.077s
best color 109,146,188 in 0.042s
[[106 66 58]
[183 172 158]]
--
best color 157,139,38 in 8.671s
best color 193,176,62 in 0.061s
[[108 70 13]
[ 18 16 3]]
--
best color 110,95,67 in 1.681s
best color 212,197,165 in 0.099s
[[ 83 67 44]
[154 150 127]]
--
best color 157,101,66 in 7.637s
best color 153,101,70 in 0.101s
[[ 75 49 50]
[150 142 160]]
--
best color 165,170,174 in 6.874s
best color 188,192,198 in 0.135s
[[ 60 57 52]
[138 140 137]]
--I'm using your max(max - min) judge of greyness rather than strict saturation which gives different results. |
Beta Was this translation helpful? Give feedback.
-
|
Paddy.. Wow - that's some really great work and those run-times are impressive! I'd be happy to replace the existing code with this assuming it produces similar results. I'll update my local repo soon and start using it. I guess to verify its accuracy, both functions could be temporarily hacked to accept the initial centroids as input, which should result in each of them producing the same (or very similar) result. And, I'm certainly not partial to my function that judges the "grayness" of a color - I just wanted some way to get the most non-gray color from the result set and that seemed reasonable at the time... :) |
Beta Was this translation helpful? Give feedback.
-
|
Jeff, I just added you mat style. Wow, this looks really, really good. I never put portraits on my frame, because this looks ugly for me. The "portrait_pairs" option was an improvement. An only portrait switch for mat would be perfect. |
Beta Was this translation helpful? Give feedback.
-
|
Just thinking about this... Maybe a good (optional) way to control it would be to compare the aspect ratio of the image to the aspect ratio of the screen. If the ratios are within some configured percentage (for example, 10%), display the image without a mat. Otherwise, add a mat. Just thinking out loud. |
Beta Was this translation helpful? Give feedback.
-
|
This is something, we should discuss with Wolfgang. All my images are exported to fit the screen size with the correct ratio. But I assume lot of people wouldn't do that. |
Beta Was this translation helpful? Give feedback.
-
|
Jeff, I was going to suggest something along the same lines (possibly even vaguer). I suppose it needs to be tied into the other options i.e. if < 10% crop the image or fill the edges, if so with blur or mirror etc. Meanwhile I tried running with both k-means functions starting from the same centroids. Normally they were close (within the nearness value used to break the iteration) but one or two were a bit further out. I tried going back/next a few times (to the same image) and I think both functions give a reasonably variable output. However if I increase max_iterations the results are nearer. So I think we should use the numpy based function. |
Beta Was this translation helpful? Give feedback.
-
Yes, this is definitely along the lines of my thinking as well. And, it plays into the "simplify the display options for the User" that I've mentioned a few times. We just need to find a good way to normalize all of the display options into a single (as much as possible), simple mechanism. Regarding the k-means functions. While I haven't played with your changes at all yet, I'm all for using the faster function assuming the results are reasonable. However, I don't understand why they don't produce the same (or nearly the same) results at each iteration - assuming they start with the same centroids. Though, I'm expecting both are intended to do exactly the same thing, and maybe that's not the case with your |
Beta Was this translation helpful? Give feedback.
-
That would be a very useful option to have. We should not forget that we are the nerds who make sure that all images on the frame fit exactly to the aspect ratio of the frame ("The Purists") but many folks couldn't care less and just send to the frame whatever is on their mobile phone from portraits, panorama, square and different landscape formats. |
Beta Was this translation helpful? Give feedback.
-
Related to this, I have something I'm happy with for mat selection now.
This feels much more natural to me than the previous 2 options and is way more flexible. I'll submit it sometime soon unless anyone has a concern. Related, I still want to handle the "auto color selections" in a cleaner manner too. I'll look at that soon. |
Beta Was this translation helpful? Give feedback.
-
|
Yes resize v. thumbnail could well be it. I assumed that I was using the same initial centroids. I added an argument to KmeansNp.run(... start_clusters) and made Kmeans.run store the initial clusters. I suppose with the RGB locations being integers there might be some pixels which are equidistant from two centroids (probably only on the first iteration) and maybe the nearest is different in the two cases (thought looking at the code I can't see why) I've not tried starting them both off from [[255,0,0],[0,255,0],[0,0,255]] maybe I will, just out of interest. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think |
Beta Was this translation helpful? Give feedback.
-
|
Yes, resize will be slower because there will be more pixels (I suspect the copying cancels out) but the proportions of the different colours should be about the same as it just stretches everything in one direction or the other. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, really, I'm most interested in getting the same image data to both versions to see if that accounts for some of the discrepancies. Otherwise, I'm sure either resize method will work fine for our purposes - so, the fastest should win. :) |
Beta Was this translation helpful? Give feedback.
-
|
Improved mat_image property handling PR here: I've removed the 3 "auto_*" properties as they were ultimately unnecessary. I will say that I struggled a bit before I realized that PyYaml doesn't properly deserialize 'None'.... :( |
Beta Was this translation helpful? Give feedback.
-
While waiting for the dust to settle on the refactor of the picture frame code base and the merging of lots of great new features, I've been working on a new option for the presentation of images.
The obvious problem for a digital frame is in presenting images that don't fit the aspect ratio of the display. There are already a number of good ways to do that in the app, including:
While option 4 above may be the best option for some, I tend to like option 3 based on my current photo library (and the various formats it contains). That said, I've been seeking something a little more "elegant".
This also plays into how I eventually want to build my frame. I already have a 16:9 aspect monitor designated for my first frame. I had decided that I was going to use the monitor to show 3:2 formatted images using a physical mat (as a few other builders on Wolfgang's site have done) by having the mat cover the left/right edges of the monitor and adjusting the software borders accordingly.
However, I do have quite a number of mobile-device photos also, which fit rather nicely in a 16:9 space. So, I began to debate whether I really wanted to waste a portion of my 16:9 display. This is what drove me to the new image presentation method.
Basically, the new method presents the image on a colored mat, with a predefined minimum border around the edges. The image is just scaled to fit the mat with the defined minimum border. Each image is presented in a float mount style with a fine line around the image itself and a drop shadow on the right and bottom edges (ATM).
Also, I've reworked the portrait pairing feature I added earlier to treat the image pairs as individual images during processing and placement. That is, when images are paired, each gets their own fine border line and shadow, and the pair is then centered on the mat with a defined space between them.
The other touch is the mat color. I've done lots of experimentation here and have decided that selecting one of the "dominant" colors from the image looks best to my eye. Though, it's also possible to simply specify a single, static mat color for everything...
The code currently buckets all of the image pixels (using a thumbnail representation for performance) into one of 3 color buckets. These are the 3 colors that best represent the entire image. Then, I select the "least gray" color from those 3 colors (again, based on experimentation, this looks best to me). That becomes the color of the mat. Then, the thin outline around the image is either a darker or lighter version of the mat color, depending on whether the mat color is already considered "dark" or "light". Finally, the drop shadow generated for the image is made using a darker version of the selected mat color.
In the case of image pairs, the color selection process is currently done on the first image of the pair and the second image just comes along for the ride. While that might not be ideal in every case, it's been satisfactory to me so far...
Anyway, with this style, I'm happy to just let the mat fill the screen and the image(s) to take up whatever room they need. So, in my case, I think I'll stick with a 16:9 aspect frame with no physical mat, and let this method fill in any extra space for me.
I still have quite a bit of clean up to do before I'd be ready to submit a PR (and, I'm currently not working with paddy's most recent code), but I wonder if there's any interest in this presentation style as part of the standard app?
Here are a few random samples generated using the method described above:
Beta Was this translation helpful? Give feedback.
All reactions