Bug 428038 - Group with two filter mask layers doesn't save layers properly when copied from another file
Summary: Group with two filter mask layers doesn't save layers properly when copied fr...
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: Animation (show other bugs)
Version: 4.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-21 00:03 UTC by problem.machine
Modified: 2021-05-06 04:33 UTC (History)
2 users (show)

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


Attachments
Comparison of source and copied versions of frames showing misalignment (17.51 KB, image/jpeg)
2021-02-03 03:15 UTC, problem.machine
Details

Note You need to log in before you can comment on or make changes to this bug.
Description problem.machine 2020-10-21 00:03:14 UTC
SUMMARY
Data saved in filter mask layers is often unsaved and these layers do not remain open in the timeline if the file is reloaded

STEPS TO REPRODUCE
Note: Because of the size limit I cannot attach the affected files directly and I am finding it difficult to reproduce the problem from scratch. I describe here how I recreate it locally. File A is a large master animation file with a few layers of line art and a couple of groups for coloring with each group containing a filter mask for shadows and a filter mask for highlights. File B is one shorter animation which I'm trying to import into File A.

1. Open File A in one window and File B in another. Go to frame 488 in File A and note that the filter mask contains entirely empty keyframes -- a result of the bug.
2. Select and drag the frames from 16-22 of shadow filter mask of File B to the frames 488-494 of shadow filter mask in File A; Select and drag the frames from 16-22 of highlight filter mask in File B to the frames 488-494 of highlight filter mask in File A 
3. Save and reopen File A


OBSERVED RESULT
The shadow filter mask still contains empty keyframes instead of the new data. Additionally, if Show In Timeline is toggled on either of the filter mask layers, this information is not saved.

EXPECTED RESULT
New information is expected to be saved

ADDITIONAL INFORMATION
I solved a similar problem with filter mask information not being saved a little while ago by toggling legacy mode on the layer, so because the behavior is similar this may be a connected problem. Additionally, the problem did not occur when I tested only copying the shadow data -- it only happened when I copied both shadow and highlight filters

Krita

 Version: 4.4.0
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.9
  Version (loaded): 5.12.9

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.18363
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
 
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (AMD Radeon (TM) R9 380 Series Direct3D11 vs_5_0 ps_5_0)" 
  Version:  "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" 
  Shading language:  "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" 
  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 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
     Version: 3.0
     Supports deprecated functions false 
     is OpenGL ES: true 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: true 

Hardware Information

  GPU Acceleration: auto
  Memory: 16326 Mb
  Number of Cores: 4
  Swap Location: C:/Users/Problemachina/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/Problemachina/AppData/Local/Temp
  Current Swap Location writable: true
  Undo Enabled: true
  Undo Stack Limit: 500
  Use OpenGL: true
  Use OpenGL Texture Buffer: true
  Use AMD Vectorization Workaround: false
  Canvas State: OPENGL_SUCCESS
  Autosave Interval: 900
  Use Backup Files: true
  Number of Backups Kept: 1
  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: false
  Use Zip64: false


Display Information
Number of screens: 2
	Screen: 0
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 2
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
	Screen: 1
		Name: \\.\DISPLAY2
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 59
Comment 1 Tiar 2020-12-11 16:49:22 UTC
> Note: Because of the size limit I cannot attach the affected files directly and I am finding it difficult to reproduce the problem from scratch.

Could you please check this: take the affected file, go to Image -> Scale Image to a new size, and then scale to something really small, like 100x100? That should make the size of the file small enough to attach but still contain the same layer structure etc.
Comment 2 Bug Janitor Service 2020-12-26 04:34:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Bug Janitor Service 2021-01-10 04:33:53 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 4 Tiar 2021-01-10 16:38:45 UTC
Reopening to Reported, since the bug report sounded legit, it would be just more helpful (easier to reproduce) if there was a test file.
Comment 5 problem.machine 2021-01-11 04:58:36 UTC
(In reply to Tymond from comment #4)
> Reopening to Reported, since the bug report sounded legit, it would be just
> more helpful (easier to reproduce) if there was a test file.

Sorry I haven't gotten a chance to try to reproduce, I deleted the malfunctioning layers to focus on linework and have not been doing animation work for the last month. I will try to reproduce the bug later this week
Comment 6 problem.machine 2021-01-16 08:31:15 UTC
(In reply to Tymond from comment #4)
> Reopening to Reported, since the bug report sounded legit, it would be just
> more helpful (easier to reproduce) if there was a test file.

Alright here are smaller versions of the files, in which the bug still seems to occur: https://www.dropbox.com/s/s3178yjt0m0064m/PlayerSprites.7z
To reproduce, copy the layers under the color folder in Crouch-Stand-CombinedSmall.kra from 120-127 to the same layers in EveMasterAnimationSmall at frame 468 via ctrl+dragging from a second window. Note that the shadow and highlight layers are now misaligned. This seems perhaps a bit different in that the issue occurs even before saving and reloading, but it is surely related.
Comment 7 Eoin O'Neill 2021-01-20 03:28:16 UTC
Hi problem.machine, 

I cannot reproduce this bug on master. Could you try loading one of your animation files with the latest version of Krita Next (available from our Downloads page) and see if this error can be reproduced?

There have been changes made to how keyframe data is stored / transitions between layers and would be interested to know if these issues described persist.

Thanks and sorry for any inconvenience,
Eoin
Comment 8 Eoin O'Neill 2021-02-03 01:41:49 UTC
I'm changing the tag on this for now...
Comment 9 problem.machine 2021-02-03 03:15:00 UTC
Created attachment 135386 [details]
Comparison of source and copied versions of frames showing misalignment

The issue still exists in 4.4.2
Comment 10 Bug Janitor Service 2021-02-03 04:33:20 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 11 Eoin O'Neill 2021-04-06 04:33:06 UTC
Hi again, problem.machine :

I still can't reproduce this in master (Krita 5). However, I have few questions regarding your issue.

1) Can you make sure that onion skinning is off before transferring content between images?

2) Can you please specify what filters you are using when the error occurs? I need to try to reproduce this issue on a minimal-content environment.

3) Can you try playing back the animation and then seeking to a new point in the animation to see if it results in a fix?

4) Lastly, you said you tested in 4.4.2 and still had the issue... However, if you could try the latest version of Krita 5's alpha build, it will be useful since a lot of the animation code under-the-hood has changed since Krita 4.

Thank you very much for your patience,
Eoin.
Comment 12 Bug Janitor Service 2021-04-21 04:33:15 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Bug Janitor Service 2021-05-06 04:33:35 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

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