Odd black/grey lines at outlines of image components

[Arboc]

If this template helps then use it. If not then just delete and start from scratch.

OS (e.g. Win10): MacOS Mojave 10.14.6 (also tried it out on a Windows 10 computer, same behavior there)
PsychoPy version: 2020.2.4
Standard Standalone? (y/n): Yes
What are you trying to achieve?:
Display image components.

What did you try to make it work?:
I set an image component to be shown in the middle of the screen, in an experiment with these screen background settings:

• Color: $[1,1,1]
• Color space: rgb
• Units: deg
• Blend mode: average

I used this image:

There is of course a “frame” inside of the image, but as you can see, there is nothing at the very borders of the image.

What specifically went wrong when you tried that?:
When I display the image in the center of the screen I get this:

There is a faint grey outline running around the image.

If I place the image not in the middle of the screen, but offset by five degrees downwards, it looks like this:

Note how for some strange reason, the line at the bottom has become thicker, while the one at the top has disappeared.

The problem becomes more obvious when using multiple image components in one routine:

I thought that the problem was Mac-specific, but the same thing happens on my colleagues’ computers running Windows.

Looking at the images in sequence like this, it’s almost like PsychoPy is putting a black/grey box behind every image component. Only this “box” juts out ever so slightly, and when you move the image component around the box moves slightly more than the image component itself. Very odd.

Why is PsychoPy adding these outlines and how can I make it stop doing that?

[TParsons]

I may be wrong, but I think what’s happening here is to do with scaling. Your image will have its own size in pixels, PsychoPy will read this in pixel by pixel, resize it and then display it to be the size you specified. I think this is probably that the exact size you want would sit wrong on the borders between pixels - which is why the outline changes at different positions. As all the pixels near the edge are white and it’s (presumably) on a white background I can’t imagine why this would matter - as it should just average the nearby pixels, which are all white.

Some things to try:

1. Changing the blend mode on the window, it may simply be that it’s blending in a weird way
2. Make sure the images are all saves as .png (which is roughly lossless) and not .jpg (which is compressed)
3. Changing the background of the image to be transparent rather than white (just try one or two to see if it works, then do the rest if it does)

Let me know if none of this works and I can have a deeper look into how images are rendered!

[Arboc]

Thanks for the response,

It’s (presumably) on a white background

Note that when I described the “background settings”, I meant the experiment-level screen color settings. Perhaps that’s not supposed to be used for changing the background color? I’ve seen suggestions of adding a rectangular polygon component stretched out to fill the entirety of the screen in order to color the background. But I thought that was only necessary if one wants to use different background colors instead of the same throughout the whole experiment. Since I wanted to use a white background for all routines it seemed excessive to put in a “white background component” for each routine. If I shouldn’t change the screen color setting, what’s a simple way to change the background color for an entire experiment?

Changing the blend mode on the window, it may simply be that it’s blending in a weird way

This didn’t work, if I instead use “add” as the blend mode then the image turns all red. This is part of what makes me think that maybe I’m not supposed to change the screen settings in order to modify the background color.

Make sure the images are all saves as .png (which is roughly lossless) and not .jpg (which is compressed)

They, including the example image in OP, are indeed saved as png’s.

Changing the background of the image to be transparent rather than white (just try one or two to see if it works, then do the rest if it does)

This does indeed work, which is odd. It would take a fair amount of time to go through and edit all the images like this manually, but maybe there’s an ImageMagick command that would come in handy. Either way it was decided anyway in our case that a grey background would be used for the experiment to decrease the strain on participants’ eyes. But maybe this thread will help someone who bumps into the same issue.

[TParsons]

Turning red when you change blend mode is an odd one - is your Color Space HSV? If so that might make sense - every value set to max in HSV should be pure red I think. Try keeping blend mode as Average and instead changing Color Space to RGB.

Setting background colour using the Experiment Settings menu is standard so you’re fine there! If you have Photoshop, you could process all the images as a batch using a Macro - just click in one corner with Magic Wand, delete and save.

[Arboc]

If you have Photoshop, …

Thanks for the tip, that sounds simple enough

Turning red when you change blend mode is an odd one - is your Color Space HSV? If so that might make sense - every value set to max in HSV should be pure red I think.

You mean for the experiment itself, right? I made a minimal reproducible example for myself by downloading the example image in OP, and creating a fresh PsychoPy (2020.2.4) experiment with just one image component pointing at the downloaded sample image.

I used these settings

And this is what things look like

The color space setting for the image component is the default “rgb” as well. The only things I modified for the image component were the size, size units (deg) and duration (20s).

If I change the background color to the default [0, 0, 0] I get the expected behavior

(it looks a bit jagged, but that’s just because the image is small and my test display is cheap)

I’ve had similar trouble before, “add” has basically never worked for me because the colors go crazy if the experiment’s background color is anything but the default grey.

[TParsons]

That dotted effect is @jon’s handiwork! Following the ethos of “if it breaks, make it obvious that it’s broken” - it does that whenever you supply a color value which isn’t in the valid range for your color space.

add most likely causes this because, essentially, it adds the colour of pixels together when they’re in the same location. So if you have a white pixel (1,1,1) on top of another white pixel (1,1,1), it could be that it’s trying to render as (2,2,2), which isn’t a valid color. It should just cap at (1,1,1), so I’ll look into why it isn’t (I’m currently reworking a lot of the behind-the-scenes stuff for Color anyway so will make a point of checking blend modes).

What happens with blend mode average, background $(1,1,1) and color space rgb?

[jon]

grey lines

What you’re seeing there is an aliasing/interpolation issue. Your black line is sitting just off the center of a pixel location and that therefore can’t be rendered perfectly as you intend. The next row of pixels is partially covered by the line so the question is what to do. If you set interpolation=True then you’ll get the grey effect you’re seeing. The next pixel line is partially black but a pixel can’t be part black, so with linear interpolation it becomes grey. If you turn that off you’ll get “nearest neighbour” interpolation instead so it will switch to an actual value from the original image (black or white not grey) but the centroid and/or thickness of the line might not now be what you expected.

red/black when blendmode=add

If you put a white image (rgb=+1) on a light coloured screen (higher than the 0 of mean grey, let’s say +0.5 for light grey) then when you ‘add’ them you get +1.5 (right?) btu that’s higher than the maximum of 1.0 so it can’t be rendered on your screen. The red (or blue for negative) let’s you know that

[Arboc]

Thanks for the reply,

Your black line is sitting just off the center of a pixel location and that therefore can’t be rendered perfectly as you intend. The next row of pixels is partially covered by the line so the question is what to do. If you set interpolation=True then you’ll get the grey effect you’re seeing. The next pixel line is partially black but a pixel can’t be part black, so with linear interpolation it becomes grey.

I’m not sure what you mean here. The image I was embedding is the first one in the OP. There are no black lines at the very borders of the image itself (note that the image has white “padding” outside of the “frame” in the image). I even tried “repainting” the very edges of the image using Photoshop with white to ensure that there are no non-white pixels that would have made it into the image somehow. The result is still the same. So there should be no black/grey lines involved at the very borders of the embedded image, and so there should be no conflict, since all the pixel color specifications (background and borders of the image itself) involved at the borders should be [1, 1, 1]. But perhaps I’m misunderstanding what you meant.

If you put a white image (rgb=+1) on a light coloured screen (higher than the 0 of mean grey, let’s say +0.5 for light grey) then when you ‘add’ them you get +1.5 (right?) btu that’s higher than the maximum of 1.0 so it can’t be rendered on your screen. The red (or blue for negative) let’s you know that

That makes sense, and I had previously thought that that might be what’s happening. @TParsons suggested that I try changing the window’s blend mode, but the only alternatives I can see for blend mode are “average” and “add”, and I was already using “average”, as I described in OP. So I tried with “add”, but I guess that was inappropriate to begin with then, since I want to embed a white image on top of a white background → net color [2, 2, 2] if “add” is used.

Again, in our case we’ve shifted over to using a grey background because of other reasons and I wrote the last couple of replies simply to help with debugging. Unfortunately I’m very short on time these days so I won’t write more about this. If you want to explore the issue described in OP more then please try downloading the image and seeing if you can reproduce it based on OP and my third post in the thread.

[jon]

@Arboc

I’m not sure what you mean here. The image I was embedding is the first one in the OP. There are no black lines at the very borders of the image itself (note that the image has white “padding” outside of the “frame” in the image). I even tried “repainting” the very edges of the image using Photoshop with white to ensure that there are no non-white pixels that would have made it into the image somehow. The result is still the same. So there should be no black/grey lines involved at the very borders of the embedded image, and so there should be no conflict, since all the pixel color specifications (background and borders of the image itself) involved at the borders should be [1, 1, 1]. But perhaps I’m misunderstanding what you meant.

Are, OK. I think this must be that the graphics card is treating the area beyond the image as being black, and therefore the interpolation calculation is still creating a grey line. I think if you set interpolation to be off you’ll get rid of it, but it’s something we should try and replicate here so we can try and fix it (but it might be graphics card specific)

[Arboc]

I tried switching Interpolate to ‘nearest’ for a new experiment I’m working on, and this does indeed solve the problem. (It might be that the fundamental issue is solved in the most recent PsychoPy version too, I’ve been asked to keep to an older one).

My graphics card, in case it’s relevant, is: Intel Iris Graphics 6100 1536 M

Thanks!

Update in 2021:

I hadn’t found it when I made this thread, but there is another thread describing the same issue that has some more information: Borders on some images - #6 by ewing

Turning linear interpolation off/using ‘nearest’ interpolation worked for the particular experiment I mentioned in this thread, but often times this causes issues with image quality. Because of this I’ve unmarked jon’s reply, to make it clear for anyone stumbling upon this thread that the issue is on-going (unless it’s been solved in the very latest PP version).