Full-res preview looks odd


It is the full-resolution preview that looks bad. The thumbnail and saved TIFF look fine.


Strange, I can’t imagine how that would happen because everything is supposed to be perfectly aligned and never partially transparent…

A few background questions: What’s the commit you’re running? What are you running it on? What graphics driver? What screen resolution? I understand this may be running in a VM, which I’ve never tried before.

What happens if you:

  1. Change the user interface scaling (in the settings tab)? Does the offset between the two images change?
  2. Turn image smoothing on and off? This mipmaps the image preview when it’s smaller than 1:1.
  3. Zoom in? Does the spacing remain constant on the scale of the screen, or on the scale of the image?

Can you take screenshots of the full window? Do the edges of the image ghost as well, or is it only in the image area itself?


Commit e960d7e8cdccda1bf63a60e05b36244f9140b857
System linuxmint-18.1-mate-64bit
Driver vmwgfx
Screen 1916x939
OpenGL 3.3

Disabling Smooth removes the problem. When enabled, misalignment and transparency starts happening at five zoom outs from 1:1. The right edge has transparency.

Fit Zoom

Fit - 1

Fit - 2

Fit - 3


I see that between different zoom levels, the stronger image moves from the left to the right of the ghost image; they also seem to change in strength relative to one another.

If you zoom in (increase magnification) with the mouse wheel, whatever is under the mouse cursor is supposed to stay precisely there. Is this the case with either of the overlapping images?


From what I can tell, going from zoom level 1:1 -6 to 1:1 -5, the right hand image (at lamp bulb) stays true to the cursor position.

1:1 -6

1:1 -5

However, when I zoom outward from 1:1 -6 to 1:1 -7 and beyond, the preview image starts jumping all over the place. Also, it looks like the transparencies change at different zoom levels.


To be honest, I want to lay the blame on the virtual machine graphics interface, because it’s breaking only when mipmapping is enabled, and I’ve never experienced this glitch before on any of AMD, Nvidia, or Intel graphics before. However, I can’t find anything about this problem online.

When I zoom in really far on your screenshots, I can see that one of the two layers has half the resolution of the previous one, which indicates that they’re two levels of detail of the mipmap. The reason one fades in and out is because as you zoom, it blends gently between different resolutions of the image. That’s why the transparency levels change when the zoom levels change: the closer one of the mipmaps gets to native resolution, the more it’s weighted. Normally this is completely unnoticeable, but in this case there’s an offset between the two levels of detail, and we get the above result.

I’m not sure there’s anything I can do, except say to turn mipmapping off (which you say eliminates the problem). Personally, I leave mipmapping off anyway because it adds a tiny bit of time to the processing, and I like the sharper image when not mipmapped.

As for checking whether the driver is actually the issue, though, can you try running a 3d application (game, maybe) and see if things like textures are screwed up? It seems like OpenGL 3.0+ (which you have) has automatic mipmap generation, so if that’s the problem then it’ll show up in other situations.


I don’t mind leaving things as they are. Just reporting what I see :smile:


I read up on https://en.wikipedia.org/wiki/Mipmap. One interesting point: at the cost of 1/3 more memory. Does this mean that if I turn it off, Filmulator will be slightly less RAM hungry?

PS You are right about it being a driver issue. Apparently, my GPU doesn’t support OpenGL 3.3.


Only marginally. Only the end result gets mipmapped, so you save as much as ~100 megabytes of memory.

However, if the graphics card cannot fit the entire photo in memory (this happened on integrated graphics with an 80MP file on an older laptop) then it simply won’t be able to show anything without mipmapping.