The "filename" field in json-array sheet data doesn't contain the filename in some circumstances about aseprite HOT 11 CLOSED

Okay, I was able to reproduce this issue but with the following command (I think you missed the input file):

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json test1.png

from aseprite.

Hi there. I'm a bit confused...the last Aseprite version in the 1.2.x series was the 1.2.40. So which version are you trying?
Anyway, you should try it in the latest one, which currently is 1.3.2.

from aseprite.

Hi there. I'm a bit confused...the last Aseprite version in the 1.2.x series was the 1.2.40. So which version are you trying?

It was indeed 1.2.40. 49 must have been a slip of the finger. Thanks for looking into this!

from aseprite.

By the way, when you have files named sequentially like test1.png, test2.png, test3.png, etc...and you use the input file test1.png, the aseprite CLI (by default) tries to load the whole sequence (starting from 1 in this case, if you use test2.png instead, the sequence will start from 2). So it is expected that the json file contains 2 frame entries. The issue here is that the filenames are wrong.
This also explains why you get 1 frame when using testa.png, and testb.png, because those files are not a sequence (they must have a number in their names before the extension's dot and after the name to be considered a sequence)

from aseprite.

@dacap I'm a bit confused...I've tried the command with an aseprite file instead of a sequence:

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json test.aseprite

And I got this:

{ "frames": [
   {
    "filename": "test 0.aseprite",
    "frame": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "sourceSize": { "w": 128, "h": 128 },
    "duration": 100
   },
   {
    "filename": "test 1.aseprite",
    "frame": { "x": 128, "y": 0, "w": 128, "h": 128 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "sourceSize": { "w": 128, "h": 128 },
    "duration": 100
   }
 ],
 "meta": {
  "app": "https://www.aseprite.org/",
  "version": "1.x-dev",
  "image": "test.png",
  "format": "RGBA8888",
  "size": { "w": 256, "h": 128 },
  "scale": "1"
 }
}

So I'm not sure what should be the correct value of the "filename" property in the frames array. I thought that in the case of a sequence it should be the name of the file (please confirm if this is the expected behavior), but in this case I'm not sure if it should be test.aseprite or something else.

from aseprite.

When

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json test1.png

is used, the test1.png is loaded as an animation automatically because test2.png exists. Then to build the sprite sheet filename value, Aseprite uses the default --filename-format parameter (which is {path}/{title} {frame1}.{extension} for animations).

We can use --oneframe to fix this default behavior

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json --oneframe test1.png

and it will output a json file with ... "filename": "test1.png", ..., and if we use

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json --oneframe test1.png test2.png

it does work as expected resulting in

{ "frames": [
   {
    "filename": "test1.png",
    "frame": { "x": 0, "y": 0, "w": 32, "h": 32 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 32, "h": 32 },
    "sourceSize": { "w": 32, "h": 32 },
    "duration": 100
   },
   {
    "filename": "test2.png",
    "frame": { "x": 32, "y": 0, "w": 32, "h": 32 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 32, "h": 32 },
    "sourceSize": { "w": 32, "h": 32 },
    "duration": 100
   }
 ],
 ...
}

from aseprite.

Got it. Then if the default format is {path}/{title} {frame1}.{extension}, and we execute the command as I first mentioned:

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json test1.png

With test2.png in the same directory as test1.png.

Shouldn't the output be:

{ "frames": [
   {
    "filename": "test 0.png",  // <-- Note that currently it outputs test1 0.png
    "frame": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "sourceSize": { "w": 128, "h": 128 },
    "duration": 100
   },
   {
    "filename": "test 1.png", // <-- Note that currently it outputs test1 1.png
    "frame": { "x": 128, "y": 0, "w": 128, "h": 128 },
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": { "x": 0, "y": 0, "w": 128, "h": 128 },
    "sourceSize": { "w": 128, "h": 128 },
    "duration": 100
   }
 ],
 "meta": {
  "app": "https://www.aseprite.org/",
  "version": "1.x-dev",
  "image": "test.png",
  "format": "RGBA8888",
  "size": { "w": 256, "h": 128 },
  "scale": "1"
 }
}

If this output should be the correct one, then it seems that the CLI is not realizing that the file title of the sequence is test instead of test1. This seems like a bug to me, right? Or am I missing something?

from aseprite.

Actually the default filename format is "{title} {frame}.{extension}" for sprite sheets:

Having said that, the current Aseprite output for the given example is correct because the {title} in sprite sheets refers to the title of the source image filename (not the output filename). That's why

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json --oneframe test1.png test2.png

Outputs {... "filename": "test1.png", ... "filename": "test2.png", ...}. Because test1.png and test2.png are the filenames of the source sprite (not the destination/output test.png).

When

aseprite --batch --sheet-pack --format json-array --sheet test.png --data test.json test1.png

is used, the source sprite filename is test1.png, and it's an animation with two frames (test2.png as its second frame). So the output correctly says {... "filename": "test1 0.png", ... "filename": "test1 1.png"...} because "{title} {frame}.{extension}" was used to generate both of those sprite filename using test1.png as the original filename (and getting its title and extension).

This is an expected behavior, I think we should close this issue until we get an exact case/reproduction where the sprite sheet output misbehave, but I think -oneframe parameter can be a fix for the confusing situation where several unrelated sprites are called test1.png, test2.png, etc. and correctly generate the sprite sheet with the proper original filenames.

EDIT: Fixed "filename": "test1 1.png"

from aseprite.

Closing as it works as expected.

from aseprite.

Thanks for the suggested flags to use to prevent this!

Maybe it works as intended, but I think it's reasonable to expect that the filename field contains the filename unless you've explicitly set --filename-format to something else.

I realize it's not a good idea to change the current default behavior since it will likely break someone else's workflow, but at the very least I think it's a documentation issue. This caught me by surprise because it wasn't documented that the filename field would not strictly contain the filename even though I had not specified a format.

from aseprite.

Maybe it works as intended, but I think it's reasonable to expect that the filename field contains the filename unless you've explicitly set --filename-format to something else.

Actually it includes the original filename, but in your first post this is a special case where a sequence of png files is loaded as an animation, in other cases, generally it should include the original filename, which it's expected they will be .aseprite files, because a sprite sheet is generated from a .aseprite file and a texture atlas from several .aseprite files, so this shouldn't be an issue in the most common case (where a static image is converted to an animation automatically in the process).

I think it's a documentation issue

I'll see what can be done to document this and other issues (actually there are a lot of missing documentation).

from aseprite.