Bug 454136 - Fill layer with plain color or gradient color become black when open from earlier Krita build
Summary: Fill layer with plain color or gradient color become black when open from ear...
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-21 08:56 UTC by Protoniv
Modified: 2022-05-22 09:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
become black in krita earlier build (27.60 KB, application/x-krita)
2022-05-21 12:19 UTC, Protoniv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Protoniv 2022-05-21 08:56:01 UTC
SUMMARY
Saving a file with Fill Layer (plain color) in May 17th nightly build (5.1.0-prealpha-1d84308df8) and open the .kra with earlier version such as 5.1.0-prealpha-e73bc4fca1 (May 7th) or 5.0.5 , the Fill Layer will become totally black, and layer property also indicate it is RGB(0,0,0)
If using Fill Layer with gradient, the applied color will become RGB(0,0,0)

If the file only have the Fill Layer and nothing else, it cannot be reproduce.

Can still be reproduced in 5.1.0-prealpha-110498db8a (May 20)

STEPS TO REPRODUCE
1. New file, add Fill Layer with any color except black in newest krita nightly build
2. Make sure the file also contain "a Paint Layer"
3. Save file, open .kra with stable build (5.0.6 or newest 5.0.7)

OBSERVED RESULT
The fill layer is black

EXPECTED RESULT
The fill layer should preserve its original color

SOFTWARE/OS VERSIONS
OpenSUSE Leap 15.3 KDE 

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2022-05-21 09:01:35 UTC
I cannot reproduce this with a build from master and the 5.0.6 appimage.
Comment 2 Protoniv 2022-05-21 12:19:58 UTC
Created attachment 149067 [details]
become black in krita earlier build

Thanks for the reply!
Strangely, I cannot reproduce with new file now, but can did it several times hours ago.
This is the file I found can be still occur the issue, the original fill color is #737373
Comment 3 Halla Rempt 2022-05-21 15:53:09 UTC
I suspect that the chinese image name might be the problem here: this might be fixed after

commit 0d7259f83d021278f9f560f676fc6b96b5a0d9c0
Author: Alvin Wong <alvin@alvinhc.com>
Date:   Tue May 17 22:04:39 2022 +0800

    win: Set activeCodePage to UTF-8
Comment 4 Halla Rempt 2022-05-21 15:56:45 UTC
Or it could be 

commit 0db3b4718cdf2da4d3461906993716bf5eb6dc66
Author: Halla Rempt <halla@valdyas.org>
Date:   Thu Mar 31 15:24:02 2022 +0200

    Set the UTF-8 codec on pretty much every QTextStream
    
    Otherwise the codec for the locale is used, and that renders files
    in-interoperable.
Comment 5 Protoniv 2022-05-22 00:57:33 UTC
Thanks a lot!
After remove the Fill Layer and add the new one (still with chinese name) in the newest krita build, the issue just gone...
Since it seems not reproduceable anymore, maybe just close this ticket?
Comment 6 Halla Rempt 2022-05-22 09:29:44 UTC
Okay, thanks for checking!