SUMMARY This happens in the 4.3.0, 4.4.1 and the Nov 30 4.4.2 alpha (git 07d5d43). It also happens with Windows 10 and the 4.4.1 installed package. It happens when importing a .jpg or a .png file as a fill layer pattern Another user has a reproducible crash on Windows in this situation but I can't reproduce that: https://bugs.kde.org/show_bug.cgi?id=429836 This is in the same 'problem area' as: https://bugs.kde.org/show_bug.cgi?id=412720 but seems different. Another bug report in this area is: https://bugs.kde.org/show_bug.cgi?id=427866 STEPS TO REPRODUCE 1. Create or obtain a .png image for use as a pattern. 2. Create a new document and add a fill layer. Choose pattern from the options and Import the .png file for use then select it (it will be at the end of the list) and press OK. [NOTE: At this stage, it looks fine] 3. Save the document as a .kra file and Close it. [NOTE: It appears in the Recent Documents list with the correct thumbnail] 4. Open that .kra file. [NOTE: It looks ok.] 5. Quit and restart and open the .kra file. [NOTE: The pattern is not visible and can't be made visible by layer visibility toggling.] 6. Add a new fill layer and select that recently imported .png pattern for the fill layer. [NOTE: The new fill layer looks ok.] 7. Save then Quit then restart and open the .kra file. [NOTE: The first made fill layer is still blank but the second made fill layer has the correct content. 8. Examine the contents of the .kra file for the fill layers. [ NOTE: The first (bad) made fill layer's .filterconfig file has the pattern value: <![CDATA[/home/{full path}/Name.pat]]>. The second (good) made fill layer's .filterconfig file has the pattern value: <![CDATA[Name.pat]]> OBSERVED RESULT See Steps To Reproduce EXPECTED RESULT The pattern should be visible after saving and reopening in a later session. SOFTWARE/OS VERSIONS Krita Version: 4.4.2-alpha (git 07d5d43) Languages: en_GB, en, en, en_GB, en Hidpi: false Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.19.0-12-amd64 Pretty Productname: Debian GNU/Linux 10 (buster) Product Type: debian Product Version: 10 Desktop: MATE OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 750 Ti/PCIe/SSE2" Version: "4.6.0 NVIDIA 450.66" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 16039 Mb Number of Cores: 8 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 0 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 1860 Use Backup Files: true Number of Backups Kept: 10 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: true Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: DVI-D-1 Depth: 24 Scale: 1 Resolution in pixels: 1280x1024 Manufacturer: Dell Inc. Model: DELL 1704FPV- Refresh Rate: 60 Screen: 1 Name: DVI-D-0 Depth: 24 Scale: 1 Resolution in pixels: 1280x1024 Manufacturer: Dell Inc. Model: DELL 1704FPV- Refresh Rate: 60
Git commit 741df3a8641a072e676c48dfb0febb2b2858ae00 by Halla Rempt. Committed on 01/04/2021 at 12:35. Pushed by rempt into branch 'master'. Set the name on the resource from the database Because many resources use the filename directly for the name, and the filename now is versioned, and we don't want the versioned filename used as the name. This fixes importing a resource and using it in a pattern fill layer. M +5 -2 libs/resources/KisResourceLocator.cpp https://invent.kde.org/graphics/krita/commit/741df3a8641a072e676c48dfb0febb2b2858ae00
I'm having similar problem in the latest Krita 4.4.7 Details: I’m on Win 10, latest krita (portable) 4.4.7 release. Issue: Fill Layer with custom pattern loaded from a file doesn’t stay after saving krita file and restarting krita and opening the file again. (I did not move krita, the pattern file or the kra file anywhere, this happens every time) How to reproduce: 1. Add Fill Layer 2. Pattern 3. Import Reference 4. Load your pattern 5. Select your pattern 6. Ok 7. Save file 8. Restart Krita 9. Fll Layer should still be in Layers but the pattern isn’t visible (the fill layer is EMPTY) .filterconfig for the fill layer after the steps above (!!!) (I replaced the username with USERNAME) <!DOCTYPE params> <params version="1"> <param name="pattern" type="string"><![CDATA[C:/Users/USERNAME/AppData/Roaming/krita/patterns/DA_S_Oil_Primed DMF cotton mid2.pat]]></param> <param name="transform_keep_scale_aspect" type="string"><![CDATA[true]]></param> <param name="transform_offset_x" type="string"><![CDATA[0]]></param> <param name="transform_offset_y" type="string"><![CDATA[0]]></param> <param name="transform_rotation_x" type="string"><![CDATA[0]]></param> <param name="transform_rotation_y" type="string"><![CDATA[0]]></param> <param name="transform_rotation_z" type="string"><![CDATA[0]]></param> <param name="transform_scale_x" type="string"><![CDATA[1]]></param> <param name="transform_scale_y" type="string"><![CDATA[1]]></param> <param name="transform_shear_x" type="string"><![CDATA[0]]></param> <param name="transform_shear_y" type="string"><![CDATA[0]]></param> </params> Just to be clear I’m loading the pattern png image from (directory not related to krita in any way, Documents is my custom documents folder not the windows built in one): D:/Documents/Resources/PaperRefs/DA_S_Oil_Primed DMF cotton mid.png If you don't restart Krita just close the document and open it again the pattern stays. If you restart krita, open the document, select properties on the empty fill layer from pravious session (firstly go through the reproduction steps above) you can find the pattern in the patterns, if you select it here now, save file then you can restart krita and the pattern will stay, below is the .filterconfig after this adjustment (!!!) <!DOCTYPE params> <params version="1"> <param type="string" name="pattern"><![CDATA[DA_S_Oil_Primed DMF cotton mid2.pat]]></param> <param type="string" name="transform_keep_scale_aspect"><![CDATA[true]]></param> <param type="string" name="transform_offset_x"><![CDATA[0]]></param> <param type="string" name="transform_offset_y"><![CDATA[0]]></param> <param type="string" name="transform_rotation_x"><![CDATA[0]]></param> <param type="string" name="transform_rotation_y"><![CDATA[0]]></param> <param type="string" name="transform_rotation_z"><![CDATA[0]]></param> <param type="string" name="transform_scale_x"><![CDATA[1]]></param> <param type="string" name="transform_scale_y"><![CDATA[1]]></param> <param type="string" name="transform_shear_x"><![CDATA[0]]></param> <param type="string" name="transform_shear_y"><![CDATA[0]]></param> </params> As you can see it's different then after the reproduction steps so I assume there's something wrong with paths after loading a new pattern and after reusing it after the restart BUT according to AhabGreybeard who confirmed this entire issue (https://krita-artists.org/t/bug-4-4-7-fill-layer-doesnt-store-a-custom-loaded-pattern-with-file-save/27572/12) the above problem (the repro steps) happen even with already built-in patterns so I don't know exactly where the problem comes from since it seems to be broader than just patterns that are newly loaded into krita. I don't know if I should open a new bug report or if this is supposed to get reopened so please if someone could let me know or make the decision ;). Thank you.
Ah, I rewrote this completely for Krita 5... Could you check with the latest krita plus build? (https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/)
(In reply to Halla Rempt from comment #3) > Ah, I rewrote this completely for Krita 5... Could you check with the latest > krita plus build? > (https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/) I gave it a try and it seems to be ok. At least I haven't encountered a problem.
Cool, thanks for testing!