Transparent picture / PNG - some edges are visible

Hello there,

I can easily import transparent PNGs into Rhino (v6). It is great for the front face of buildings. But in rhino, the upper edge has a faint pixel line. You can see it in rhino itself and in my render program (simlab composer) I checked it in photoshop an affinity photo, it is 100% transparent on the edges.


Simlab VR Viewer:

Does anyone have an idea?
Thank you :slight_smile:

Edit: here you find the picture Große Diesdorfer Straß (5.6 MB)

Trim a slice off from the top… I have found this the only option in these situations

1 Like

but for the sake of the future, i would also prefer not to slice it off. @pascal @stevebaer can you confirm that this is a bug, or what is happening here. i tried png with all sorts of settings, non yield an image without boarder, all pngs where clean at the edges.

Hi @bodzguard,

can you please attach one of the PNGs causing this problem?

I edited the original post.

hi @nathanletwory just take any png with transparency turn off surface edges in whatever mode you are and look carefully at the edges around the frame

Did you check the alpha channel? From the looks of the screenshots it’s not a consistent artifact, it would seem to in fact be in the files, that’s why you should post one for them to check.

a transparent png has no extra alpha as such . the transparency is saved directly in the image. rhino does something with it that should not be.

here one of the first png with transparency i could find typing png into google.

the bottom pixels are repeated so looks like a mapping issue to me
edit: below the same image but then with 1 extra transparent row at the bottom solves it:

@bodzguard thank you for the image. I indeed can see the line with this image - I haven’t figuret yet out why. It does look like a mapping problem as @Gijs suggests. The weird thing is that I even see it even with Raytraced.

I’ve logged this as

Note that adding extra pixel rows isn’t fixing the issue. but working around :slight_smile:

edit: even worse, I see the bottom pixel row repeated even in non-tranparent textures…


And the top of that image imported as a picture in front:


@bodzguard, just for the record, can you please run the Rhino command _SystemInfo and paste the text it generates in this thread? Thank you.

Sure, here it is :slight_smile:
sysinfo.txt (1.9 KB)

Thank you!

Argh, already in 6.14 :open_mouth: I wonder why no-one (including use) hadn’t noticed that before…

@nathanletwory this is probably a stone age old bug, since sure longer as i use rhino 10 years. just to be sure i understand correctly, it is not only the last line but actually all around the boarder

@nathanletwory thank you for your help and for registering the bug!

In closer inspection, I think it is not a mapping issue but a blur issue. So the blur affects pixels at the opposite side as if it is tiled


btw: I can solve the issue completely in Vray by changing filter blur to 0

isn’t this the default behavior with tiled textures - bi-linear interpolation works on ‘centers’ of pixels - so what in the grid view is a pixel, once interpolated becomes the center of a bi-linear interpolation?
I saw this long ago in rhino, and wanted to report it, but after closer inspection i realized that it is inherent to how textures are drawn.

Still it would be nice to have a ‘repeat’, ‘clamp’ and mirror option in textures uv (respecting transparency)

in other words - i noticed this when trying to solve a problem with ‘pixel perfect’ textures, just to realize that the pixel that had a left top corner of 0,0 in opengl (and any similar context) was suddenly at 0.5 / 0.5 and would always have to take the missing information part from the ‘other end’ when set to repeat, which is the default

These already exist in Rhino:


UV afaict is secondary to that.

That is strange, I see the same with that file. BUT when I tested with a simple PNG from the net and I do not see any artifacts along any edges. Neither when used as a picture object nor if added as a material with or without repetitions.

Here is the file I used.

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. (Source)