Low image quality on exports
espindola opened this issue · 22 comments
I am using f4d31c4
The attached screenshots of demo mode illustrate the problems. The first one is that the resolution is low. It seems to have something to do with HiDPI displays. I was able to hack it locally by multiplying the width and heighth by 2, but I am not sure what the proper fix is.
The other problem is that some lines are broken.
Everything looks good when running OpenHantek, it is only the exported pngs that are bad.
Computer environment (please complete the following information):
I am running alpine linux 3.17, but I have been able to reproduce this with a debian stable chroot. Somehow the issue is not present on arch linux with version 3.3.2.1-1.
Given that it fails with a debian stable chroot, I suspect that somehow the sway or kernel version is relevant:
linux-lts-5.15.95-r0
sway-1.7-r4
- Video hardware: [e.g. Intel Xeon ... Integrated Graphics]
Intel Corporation HD Graphics 620 (rev 02)
- OpenGL version: [e.g. OpenGL 4.5, Mesa 19.0.3]
Graphic: 4.6 (Compatibility Profile) Mesa 22.2.5 - GLSL version 1.20
- Qt version: [e.g. Qt 5.11.x]
qt5-qtbase-5.15.6_git20221010-r0
- C++ compiler version: [e.g. gcc 8.3.x]
gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924
Scope device (please complete the following information):
demo mode
I expanded the experiment by installing fedora 37 in a VM and producing screenshots from the vm and then mounting the qcow2 image, chrooting into it and producing new screenshots. As far as I know, the only thing from alpine 3.17 being used in the chroot case is the wayland compositor (sway) and the kernel.
The 4 images are attached.
fedora-in-vm-screenshot:
fedora-in-vm-hardcopy:
fedora-in-chroot-screenshot:
fedora-in-chroot-hardcopy:
Just for reference - Fedora 36 (64 bit), KDE, Wayland. Attached are demo mode screenshot, hardcopy and the whole window captured with spectacle.
I was able to hack it locally by multiplying the width and heighth by 2, but I am not sure what the proper fix is.
@espindola
Which screen resolution do you use?
Where did you multiply by 2?
Please give me a chance to understand the issue - I do not see this behaviour on my laptops (1280x800 and 1920x1080).
I also have HiDPI monitor 3840x2112 and the same problem.
I think we need option to set waveform line width.
set waveform line width
I already tried this long ago. Unfortunately this is not possible with the OpenGL graphics. The option for line width doesn't work - the width stays always "1".
The OpenGL implementation is more than 10 years old when hi dpi was not common. :(
I was able to hack it locally by multiplying the width and heighth by 2, but I am not sure what the proper fix is.
@espindola Which screen resolution do you use? Where did you multiply by 2? Please give me a chance to understand the issue - I do not see this behaviour on my laptops (1280x800 and 1920x1080).
My laptop resolution is 3200x1800, but sway is configured to scale it by 2 (" scale 2" in the config file). I did the hack of multiplying by 2 by adding
int sw = screenshot.width();
int sh = screenshot.height();
+
+ screenshot = screenshot.scaled( sw *= 2, sh *= 2 );
+
I should probably try a KDE or Gnome session to compare. Will hopefully have that tonight.
Thinks look OK on my desktop, which has a 4K display (but is running arch, which has a newer version of sway).
I also have HiDPI monitor 3840x2112 and the same problem. I think we need option to set waveform line width.
Are you using Wayland or X? Which compositor?
I also have HiDPI monitor 3840x2112 and the same problem. I think we need option to set waveform line width.
Are you using Wayland or X? Which compositor?
Currently X11, Kwin.
I got the same issue with gnome instead of sway. Note that the take a regular screenshot (not via the OpenHantek menu) works just fine. One captured with grim is attached.
Looks like QT knows to do something different when outputting directly to the screen instead of to a QPixmap.
One possible workaround is to disable the hdpi scaling just to produce the screenshot/hardcopy. This is what I got when I did that:
@espindola What are your values of sw and sh before you scale them? About 3200x1800 or 1600x900 (scale2)?
int sw = screenshot.width();
int sh = screenshot.height();
+ qDebug() << "screenshot size:" << sw << "x" << sh;
screenshot = screenshot.scaled( sw *= 2, sh *= 2 );
@espindola What are your values of sw and sh before you scale them? About 3200x1800 or 1600x900 (scale2)?
int sw = screenshot.width(); int sh = screenshot.height(); + qDebug() << "screenshot size:" << sw << "x" << sh; screenshot = screenshot.scaled( sw *= 2, sh *= 2 );
I got:
screenshot size: 1596 x 841
Ok, you get the downscaled size and upscale it to the correct 1:1 size.
Now the question, how to know if you're downscaling by 2 (or even by 4)?
A quick solution would be to make it a persistent config option that defaults to 1 and can be changed in the range of e.g. 1..8 - dunno if you have a better idea to detect it automatically.
Ok, you get the downscaled size and upscale it to the correct 1:1 size. Now the question, how to know if you're downscaling by 2 (or even by 4)? A quick solution would be to make it a persistent config option that defaults to 1 and can be changed in the range of e.g. 1..8 - dunno if you have a better idea to detect it automatically.
Given that the image looks OK when drawing directly (not writing to the QPixmap), Qt must know this somehow (see #353 (comment)) , but I don't know where to look.
Please try the latest unstable - set scale factor in menu Oscilloscope/Settings/Scope/Upscale exported images
Please try the latest unstable - set scale factor in menu
Oscilloscope/Settings/Scope/Upscale exported images
The resolution is fixed, but some lines are still broken. Compare with #353 (comment)
Which value did you set? 2?
Which value did you set? 2?
Yes, 2.
strange, then it should give the same result as your
+
+ screenshot = screenshot.scaled( sw *= 2, sh *= 2 );
+
But now another shot in the dark -> new unstable (1e7788b)
But now another shot in the dark -> new unstable
Fixed!
