Bug 487483

Summary: Krita fails to save transparency masks for specific animated fill layers
Product: [Applications] krita Reporter: Michael Eric Oberlin <vikinghelmet99>
Component: AnimationAssignee: Emmet O'Neill <emmetoneill.pdx>
Status: RESOLVED FIXED    
Severity: major CC: emmetoneill.pdx
Priority: NOR    
Version First Reported In: 5.2.2   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
Latest Commit: https://invent.kde.org/graphics/krita/-/commit/d7002f1e41c8db9537eb6b73dec663d8b7b7f3ee Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Zip of example file and video of bug happening

Description Michael Eric Oberlin 2024-05-24 15:00:51 UTC 
***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
Critical data can be lost when saving an animation to the kra file format.

When a new fill layer is added and cleared with the delete key, all new animation frames will begin blank instead of solid. Changes can then be made as per usual, and committed to new frames; and for that run, both animation playback and rendering through FFMPEG will work fine. This feels like a feature. However, once the file is saved as a .kra, closed, and reopened, the detail of the layer being cleared is lost, and all frames of that fill layer are solid-color again.

This has, of course, cost me a lot of time! So I did some digging to figure out what it was that was causing it.

I am enclosing both a final file which this has happened to, and a video of it happening, to make tracking this bug easier.


STEPS TO REPRODUCE
1.  Create any Krita file in the animation workspace
2.  Add a fill layer
3.  Press "delete" to clear the layer
4.  Add a new frame at the beginning of the file
5. Move to another frame, press new frame (note that the frame is cleared to blank, not solid)
6. Do some brush strokes on this additional fill layer frame
7. Verify proper playback and export
8. Save file
9. Close file
10. Re-open file

Note that your alterations of your second frame are now completely missing, and replaced with a solid frame.

OBSERVED RESULT

Solid color over the entire frame

EXPECTED RESULT

The modifications made the last time that Krita was open

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KUbuntu 22.04
(available in About System)
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION

I'm not sure how much help the mis-saved .kra is going to be, so I'm also adding a video of this exact event occurring.
Comment 1 Michael Eric Oberlin 2024-05-24 15:11:29 UTC 
Created attachment 169778 [details]
Zip of example file and video of bug happening

Couldn't upload the original file as my screen capture was too big! So I uploaded it unlisted on YouTube: https://youtu.be/33-hLlkbjVM

This should provide a satisfactory example of the UX for the bug and hopefully help chase it down.
Comment 2 Michael Eric Oberlin 2024-05-24 15:12:11 UTC 
Comment on attachment 169778 [details]
Zip of example file and video of bug happening

Video is now on YouTube, only the file and its backup are in the zip. (It was too big for the system.)
Comment 3 Emmet O'Neill 2024-09-17 00:04:25 UTC 
I was able to confirm this.

Thanks for the bug report, Michael.
Comment 4 Emmet O'Neill 2024-10-17 02:54:49 UTC 
Git commit d7002f1e41c8db9537eb6b73dec663d8b7b7f3ee by Emmet O'Neill.
Committed on 17/10/2024 at 02:54.
Pushed by emmetoneill into branch 'master'.

KRA Saving: Fixed issue where animated FillLayer transparency masks were not saving correctly.

An optimization (I think) in the KRASaveVisitor's handling
of GeneratorLayers was causing the contents of animated FillLayer
transparency masks to save incorrectly when the active frame
at the time of saving was empty.

M  +2    -1    plugins/impex/libkra/kis_kra_save_visitor.cpp

https://invent.kde.org/graphics/krita/-/commit/d7002f1e41c8db9537eb6b73dec663d8b7b7f3ee