Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI --save-as renders hidden layers when exporting a group #2084

armandniehaus opened this issue Jun 8, 2019 · 1 comment


Copy link

commented Jun 8, 2019

When using the CLI to export a group to a single image file any hidden child layers in that group are also rendered to the resulting image.

For example:

aseprite -b test_file.aseprite --layer test_group --save-as "result.png"

(Where 'test_group' is a group, not a layer). The CLI seems to ignore whether or not any of the child layers (or groups) are hidden. The image does render correctly when no specific layer/group is provided through --layer.

Aseprite and System version

  • Aseprite version: v1.2.11
  • System: MacOS 10.13.6

@dacap dacap added the bug label Jun 8, 2019

mrspeaker added a commit to mrspeaker/aseprite that referenced this issue Aug 1, 2019
Prevent CLI render of hidden layers in group when exporting
When using the CLI to export a group to a single image file any hidden
child layers in that group are also rendered to the resulting image.

The reason is that `isVisibleHierachy()` is never checked when there
are items in `includeLayers`: as it's assumed the layers are never groups. This
commit checks if the hidden layer was explicitly included (when you want to
render a hidden layer). If not then it is a child of a group, so is not rendered.

I have tested this with many includes and excludes, with groups and
layers and it seems correct: BUT! I do not have a lot of
experience with CPP (I just needed this fix!) so this code might not be canonical.

Resolves aseprite#2084

This comment has been minimized.

Copy link

commented Aug 28, 2019

I've uploaded a test image and made some tests (writing down some information here for future reference and to keep my mind in order).


Screen Shot 2019-08-28 at 09 34 05

Tested commands:

aseprite -b groups3abc.aseprite -layer a -save-as groups3-a.png
aseprite -b groups3abc.aseprite -layer b -save-as groups3-b.png
aseprite -b groups3abc.aseprite -layer c -save-as groups3-c.png
aseprite -b groups3abc.aseprite -layer a/a -save-as groups3-aa.png
aseprite -b groups3abc.aseprite -layer a/b -save-as groups3-ab.png
aseprite -b groups3abc.aseprite -layer a/c -save-as groups3-ac.png
aseprite -b groups3abc.aseprite -layer b/a -save-as groups3-ba.png
aseprite -b groups3abc.aseprite -layer b/b -save-as groups3-bb.png
aseprite -b groups3abc.aseprite -layer b/c -save-as groups3-bc.png
aseprite -b groups3abc.aseprite -layer c/a -save-as groups3-ca.png
aseprite -b groups3abc.aseprite -layer c/b -save-as groups3-cb.png
aseprite -b groups3abc.aseprite -layer c/c -save-as groups3-cc.png
Current Output Output with #2129
Screen Shot 2019-08-28 at 13 58 13 Screen Shot 2019-08-28 at 13 59 17

I think the #2129 correctly fixes the main case (groups3-c.png) but both implementations (old one and new one) have some problems handling group names with the same name that the children. I'll take this issue from here, the expected result should be something like this:


@dacap dacap self-assigned this Aug 28, 2019

@dacap dacap added this to the v1.x-bugs milestone Aug 28, 2019

@dacap dacap closed this in 5b782dc Aug 29, 2019

@dacap dacap modified the milestones: v1.x-bugs, v1.2 Aug 29, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.