4k image edge issue

[sapnho]

I have a really weird issue with my 4k frame.

My images are all formatted to 3840 x 2160 which is exactly the pixel size of my display. On some of the pictures, I have a thin line which is a continuation of the right side area. On some, there isn't.

I have attached an example (you can disregard the fact that the image is currently in transition, it doesn't matter in this case). You can see on the right side a white area and a small part of that on the left. I have tested that with a number of images, and on most of them, this very thing happens.

I was wondering if changing a setting in configuration.yaml would bring about a change, but I wouldn't know where.

Here is the viewer part of my config file:

viewer: blur_amount: 12 # default=12, larger values than 12 will increase processing load quite a bit blur_zoom: 1.0 # default=1.0, must be >= 1.0 which expands the backgorund to just fill the space around the image blur_edges: False # default=False, use blurred version of image to fill edges - will override FIT = False edge_alpha: 0.0 # default=0.5, background colour at edge. 1.0 would show reflection of image fps: 7.0 # default=20.0 background: [0.2, 0.2, 0.3, 1.0] # default=[0.2, 0.2, 0.3, 1.0], RGBA to fill edges when fitting blend_type: "blend" # default="blend", choices={"blend", "burn", "bump"}, type of blend the shader can do font_file: "/home/pi/picframe_data/data/fonts/NotoSans-Regular.ttf" shader: "/home/pi/picframe_data/data/shaders/blend_new" show_text_fm: "%b %d, %Y" # default "%b %d, %Y", format to show date over the image show_text_tm: 20.0 # default=20.0, time to show text over image with file name show_text_sz: 40 # default=40, text character size show_text: "" # default="title caption name date folder location", show text, include combination of words: title, caption name, date, location, folder text_justify: "C" # text justification L, C or R fit: False # default=False, True => scale image so all visible and leave 'gaps'

False => crop image so no 'gaps'

auto_resize: True # default=True, set this to False if you want to use 4K resolution on Raspberry Pi 4.

You should ensure your images are the correct size for the display")

kenburns: False # default=False, will set fit->False and blur_edges->False display_x: 0 # offset from left of screen (can be negative) display_y: 0 # offset from top of screen (can be negative) display_w: null # width of display surface (null->None will use max returned by hardware) display_h: null # height of display surface use_glx: False # default=False. Set to True on linux with xserver running mat_images: 0.01 # default=0.01, True, automatically mat all images. False, don't automatically mat any images. Real value, auto-mat all images with aspect ratio difference > than value mat_type: float # default=null, A string containing the mat types to choose from when matting images. It can consist of any or

all of 'float float_polaroid float_color_wrap single_bevel double_bevel double_flat' (null or '' will use all mat types)

outer_mat_color: null # default=null, Color of the outer mat as an RGB list. null will auto-select a reasonable color based on the image. inner_mat_color: null # default=null, Color of the inner mat as an RGB list. null will auto-select a reasonable color based on the image. outer_mat_border: 75 # default=75, Minimum outer mat border in pixels inner_mat_border: 40 # default=40, Minimum inner mat border in pixels (for styles that use it) outer_mat_use_texture: True # default=True, True uses a texture for the outer mat. False creates a solid-color outer mat. inner_mat_use_texture: False # default=False, True uses a texture for the inner mat. False creates a solid-color inner mat. mat_resource_folder: "/home/pi/picframe_data/data/mat" # Folder containing mat image files

[jgodfrey]

Hi Wolfgang,

While I don't have an answer, perhaps you could clarify this statement:

On some of the pictures, I have a thin line which is a continuation of the right side area.

Are you saying that (in the sample image):

• The white area on the right edge is (correctly) part of the image, but it's being (incorrectly) carried over onto the left edge

... or ...

• The white area is not correct on either side of the image.

I assume the latter, but wanted to verify.

Does it consistently happen on the same images or does it not happen sometimes on images where you've seen it before?

Is it always in the same location?

[sapnho]

Hi Jeff, yes

The white area on the right edge is (correctly) part of the image, but it's being (incorrectly) carried over onto the left edge

Yes, the white area is correct on the right side but it shouldn't be on the left side.

Does it consistently happen on the same images or does it not happen sometimes on images where you've seen it before?

It happens consistently on the same images and the position is always exactly mirrored from the right to the left.

I first thought that it might have something to do with https://www.thedigitalpictureframe.com/pi3d-parameters-directory-config/#Background_color_at_edge but I don't have that activated and the images fit the screen dimensions to the pixel.

What I find completely puzzling is that I made a test with the image below which should result in a very thin interrupted white stripe on the left mirrored from the right. But on this particular image, it doesn't happen. On most others, however, it does.

All images are exported from Lightroom, even the test image.

[jgodfrey]

Certainly could be a bug I guess, though it would seem to be lower-level than the frame software (maybe pi3D?). @paddywwoof would know more here...

Otherwise, I wonder if it could be related to the RPi's overscan settings or custom HDMI timing settings? Though, I'd expect those would give consistent results.

It might be interesting to see if changing the overscan settings has any impact.

[sapnho]

Overscan is set to disable_overscan=1

Otherwise, I wonder if it could be related to the RPi's overscan settings or custom HDMI timing settings? Though, I'd expect those would give consistent results.

Just to make sure that I put it correctly: The results are consistent for a particular image, but not all images have this mirroring line effect.

[paddywwoof]

Wolfgang, is the whole of the right side or does it happen at a certain distance up screen? It seems like a rounding effect and I suppose it could be due to using medium precision floats for the texture lookup. But I can't really think what the mechanism would be - especially if it happens on some images and not others. If the resolution of the floats can't access the full resolution of the image then maybe the OpenGL automatically uses the mipmap.. I suppose you could test the the highp shaders by just copying those files into wherever picframe has been installed. Might be /usr/lib/python3/dist-packages/picframe/data/shaders/ if you back up the existing two files you could try putting in the files from https://github.com/helgeerbe/picframe/tree/glsl_highp/picframe/data/shaders

[jgodfrey]

Just to make sure that I put it correctly: The results are consistent for a particular image, but not all images have this mirroring line effect.

Yes, that was clear. I just meant to say that I'd think that an RPi setting (for example, overscan) would give you the same results for all images - not some good, some bad...

[sapnho]

Wolfgang, is the whole of the right side or does it happen at a certain distance up screen?

My impression is that the colors are picked up from along the entire right side.

Will try the highp shaders tomorrow. Thanks!

[sapnho]

Just tried the new files already, but unfortunately, they didn't make a difference.

It's like 2/10 of a millimeter from the right side is copied over to the left side.

[paddywwoof]

It might still be a rounding error. I will look at the code - maybe it needs to have 0.5 / 3840.0 added (or subtracted).

The other thing is the edge pixel treatment. OpenGL can either wrap or reflect or discard texture lookup going over the edge of the 0.0 to 1.0 range and this can cause a pixel from one edge to appear at the other side. However I was fairly sure that picframe was set up to reflect. I will check that.

[sapnho]

Some more information on this issue. I am not sure why but when I used my test image again today (with the new highp shaders), it also showed the effect.

[sapnho]

It might still be a rounding error. I will look at the code - maybe it needs to have 0.5 / 3840.0 added (or subtracted).

The other thing is the edge pixel treatment. OpenGL can either wrap or reflect or discard texture lookup going over the edge of the 0.0 to 1.0 range and this can cause a pixel from one edge to appear at the other side. However I was fairly sure that picframe was set up to reflect. I will check that.

Hi @paddywwoof : Any new thoughts on this? Thanks!

[paddywwoof]

Hi, No joy with this so far - but I haven't done any very systematic testing. The argument to mirror is set i.e. here so that won't help. I have a feeling there is a basic rounding error in pi3d as sometime I think there is a pixel missing at the edge of the screen, also the pi3d_demos.Conway program that uses the GPU to do the Game of Life calculation sometimes shifts diagonally and sometimes doesn't depending on what it's running on

[sapnho]

Hmmm, any chance to take another shot at this issue? :-)

[paddywwoof]

Sorry Wolfgang, I've been diverted onto other topics. I will see if I can find what causes the random movement on the Conway simulation as that ought to be fixed anyway and it might throw something up relevant to the 4K issue.

[sapnho]

Thanks so much, Paddy. That would be so great!