Please take a screenshot of the problem.
We have never been notified of anything like this or seen it ourselves.

Maik

Created attachment 174300 [details]
Example of thumbnails before moving photos

Normal view of photos

Created attachment 174301 [details]
AFTER - Blue hued discolored photos

Change of thumbnail colors after moving photos

This must be some kind of graphics card/driver or Wayland problem. Things like the pick icons are not touched by us at all during this process when moving files.
Are you using the Snap package from Ubuntu with the sandbox? Please test our AppImage to see if the problem occurs with it too.

https://files.kde.org/digikam/

Make AppImage executable and start it. Please report.

Maik

(In reply to sendtoworthington from comment #0)
> SUMMARY
> When moving photos to new album location, the color get affected and all
> photos have a "blue" hue filter applied. Restart of program fixes the issue.
> 
> STEPS TO REPRODUCE
> 1. Select photos in existing album
> 2. Right click and select move photos
> 3. Select existing or new album to move photos too
> 
> OBSERVED RESULT
> Operation completes normally.
> Color of all thumbnails and screen / theme is altered and blue overlay / hue
> is seen on everything. This affects operation (all flags are colored blue,
> all color picks color are changes).
> 
> EXPECTED RESULT
> No affect on color or theme
> 
> SOFTWARE/OS VERSIONS
> Windows: 
> macOS: 
> (available in the Info Center app, or by running `kinfo` in a terminal
> window)
> Linux/KDE Plasma: docker, ubuntu
> KDE Plasma Version: 
> KDE Frameworks Version: 
> Qt Version: 
> 
> ADDITIONAL INFORMATION

KDE Frameworks 6.6.0
Qt version 6.7.3

(In reply to Maik Qualmann from comment #4)
> This must be some kind of graphics card/driver or Wayland problem. Things
> like the pick icons are not touched by us at all during this process when
> moving files.
> Are you using the Snap package from Ubuntu with the sandbox? Please test our
> AppImage to see if the problem occurs with it too.
> 
> https://files.kde.org/digikam/
> 
> Make AppImage executable and start it. Please report.
> 
> Maik

I am using docker package for this deployment - uses KasmVNC. 

Maybe it is not a digikam issue, but a problem with the VNC wrapper they use?

It can't be a digiKam problem, I suspect it's more likely VNC.

With the thumbnails, you could imagine that digiKam might be involved, but with the colors of the pick labels and the text color of the tags - no.

However, it is also strange why this is triggered with VNC when moving files.

Maik

(In reply to Maik Qualmann from comment #7)
> It can't be a digiKam problem, I suspect it's more likely VNC.
> 
> With the thumbnails, you could imagine that digiKam might be involved, but
> with the colors of the pick labels and the text color of the tags - no.
> 
> However, it is also strange why this is triggered with VNC when moving files.
> 
> Maik

I appreciate your responses. I have opened a bug request on github for lsio digikam package. Let's see if they can be of any help.
Thank you again!

One thing you could try in digiKam is to force Software OpenGL in the digiKam settings under Miscellaneous->System (restart digiKam).

Maik

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

*** Bug 495010 has been marked as a duplicate of this bug. ***

force software open GL does not fix it.  In addition when it is closed and reopened it works, but only for a while.  It does go back to purple hued inconsistently.

Created attachment 175055 [details]
attachment-1795380-0.html

I've resorted to closing the app (top right X button) and right click restart the app from the vnc window. It's a bandaid, but can't understand the cause for the vnc issue and lsio has not found a solution yet. 

-----Original Message-----
From: bugzilla_noreply@kde.org
To: sendtoworthington@gmail.com
Sent: Sun, 20 Oct 2024 6:29 AM
Subject: [digikam] [Bug 493936] Colors of theme inverted or changed after moving photos to new album.

https://bugs.kde.org/show_bug.cgi?id=493936

--- Comment #12 from simonmcnair@gmail.com ---
force software open GL does not fix it.  In addition when it is closed and
reopened it works, but only for a while.  It does go back to purple hued
inconsistently.

Well, we at digiKam won't be able to do anything about this. The problem seems to affect QPixmap graphics.
Note this from the Qt doc:

Note that the pixel data in a pixmap is internal and is managed by the underlying window system.

QPixmap represents a platform native pixmap, can even use hardware acceleration depending on the system.
The problem must therefore be sought in the underlying operating system or the VNC connection.

A bug request to Qt directly might also be an option. However, we only know of the problem from KasmVNC. The problem could also be out of scope for Qt.

Maik

The problem may be fixed for digiKam-8.5.0 in git/master now. Select Album Dialog, Delete Dialog or the digiKam Setup used the Qt function WinId() in the constructor of the dialogs to force the creation of a window handler to set the appropriate window size. This function led to crashes or incorrect graphics output under Wayland, depending on the graphics driver. See Bug 494993 or Bug 468980.

Maik