Created attachment 164730 [details] Image causing crash SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Open image containing a face 2. Scan for faces 3. Start filling in name OBSERVED RESULT Crash after some delay EXPECTED RESULT Dropdown list with matching names SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION This happened with different images. Attached is one of the images.
Fixed in 8.3.0 with Bug 477871 Install the pre-version avaialble here : https://files.kde.org/digikam/
This worked!
I got two other problems that I didn't have in 8.2.0. Therefore I went back to the released version: - The font size on one of my monitors (3840 x 2160) is much smaller than in 8.2.0; - After I rescanned one of my drives and added a tag to all found video footage I had extra copies (_v1, sometimes even _v2, _v3) of most of the files.
Qt6 now always uses HiDPI scaling, this can no longer be deactivated. You have to adjust the fonts in the digiKam settings accordingly. t is not possible to create “_v1” files by scanning and tagging. These files are created during file operations such as copying, renaming, importing or image editing and versioning. Maik
Created attachment 165090 [details] Screenshot of digiKam on an UHD display
Created attachment 165091 [details] Screenshot of a different program on the same display I can change the font of the icons in digiKam, but not the size of the toolbars and the top bar. The fonts of digiKam 8.3.0 are smaller than the fonts of 8.2.0. Version 8.2.0 was good. I understand from Microsoft feedback that this may ne an app issue. https://support.microsoft.com/en-us/topic/windows-scaling-issues-for-high-dpi-devices-508483cd-7c59-0d08-12b0-960b99aa347d.
Please test the new option "force software OpenGL" in the digiKam settings under Miscellaneous->System. What scaling factor value (100%, 125%, 150%...) have you set in the Windows display settings? Maik
Force software OpenGL does not make a difference, scaling factor is 150%, dimensions are 3840 x 2160.
The problem does not exist here under Windows 11 with a UHD screen (Intel Graphics). Do you perhaps have a Qt environment variable set for scaling? Please check with the Windows Environment Variable Editor. Maik
Why did you reopen this entry ? What did you show with your screenshot ? Gilles Caulier
Created attachment 165097 [details] Environment variables I don't think I have a Qt environment variable set. My Environment Variables are attached.
@Gilles - It is a reaction to this reply from Mike: "Qt6 now always uses HiDPI scaling, this can no longer be deactivated. You have to adjust the fonts in the digiKam settings accordingly." in this conversation.
To test, please set the following environment variable like QT_Logging_RULES: Variable: QT_SCALE_FACTOR Value: 1.5 Maik
The cause is probably this Qt bug: https://bugreports.qt.io/browse/QTBUG-110681 This will only be fixed in Qt-6.7, although this bug report is about users with 2 screens, but single screens can also be affected. Do you possibly have 2 graphics cards in your system? Maik
I have two displays in my Windows 10 system, a 3840 x 2160 display with scale setting 150% and a 3440 x 1440 display with scale setting 100%. On both displays the scale is smaller for digiKam 8.3.0 than for any other program, including digiKam 8.2.0. Both displays are connected to a Gigabyte GeForce RTX 3070 GAMING OC 8 GB V2 LHR. I don't see a difference after setting Variable: QT_SCALE_FACTOR to value: 1.5.
Then you are affected by the Qt bug, which will first be fixed with Qt-6.7. I'm closing here now, the crash has been fixed. Maik
When I open Digikam 8.3.0 from the taskbar on my 3440 x 1440 display and then drag it to the 3840 x 2160 display then the fonts are still too small. If I open it from the taskbar on my 3840 x 2160 display they are correct.
Qt-6.7.0, which probably fixes the problem, is not yet available to us under Windows. Maik