Exported video dimensions often odd

aaronjheng

I'm frequently running into an issue where Spine's video export (MOV) produces odd-numbered dimensions (e.g. 721×1081, 499×777, 1081×1921, etc.), even though my target resolutions are usually even (like 1920×1080, 1280×720, etc.).
From what I understand, this happens because:

Spine calculates the export size based on the maximum bounds of the skeleton across all keyframes.
Attachment positions, scales, and rotations often result in floating-point bounding boxes, and when ceiling-ed to pixels, one or both dimensions end up odd.

This causes problems downstream because many video codecs (especially h.264) prefer or strictly require even dimensions (divisible by 2) for macroblock/chroma subsampling reasons. Odd sizes can lead to:

Encoding warnings/errors
Automatic cropping/padding by tools like ffmpeg
Slight quality loss or compatibility issues in some players/pipelines

What I've tried so far:

Using Fit mode + manually entering even target dimensions (e.g. 1920×1080) — works sometimes, but if the animation bounds don't match perfectly, it can crop or leave empty space unevenly.
Using Scale mode — dimensions still follow max bounds → often odd.
Adding a large transparent dummy image at the bottom of the draw order to force bigger even bounds — this is the most reliable workaround right now, but feels like a hack and increases setup time.

Is there (or could there be) an official setting/checkbox in the Export dialog to:

Force even width/height (e.g. by padding to next even number, or ceiling to next multiple of 2)?
Or at least an option like "Round bounds to even pixels" / "Ensure divisible by 2"?

It would save a lot of manual workarounds, especially for people exporting to video for web, social media, or further editing/encoding.

Thanks in advance for any advice or insights!

Misaki

aaronjheng Using Crop is likely the best solution. This is because, once you’ve set the appropriate crop position and area, you can save those export settings as a .json file and use it to run the export from the CLI, making it easy to share and apply the same settings to any Spine project.

If you're not familiar with the CLI, this might sound daunting, but it's actually quite simple if you use the export script we've made available. We've included some videos in the blog post below that explains how to use it, so we'd love for you to give it a try.
https://esotericsoftware.com/blog/New-export-shell-scripts

Spinebot

The issue you're describing is a known limitation of how Spine calculates export bounds. As you correctly identified, Spine determines the export dimensions by checking the bounds at each frame and using the maximal bounds, which can result in odd-numbered dimensions due to floating-point calculations.

Current Workarounds:

Your approach of adding a transparent dummy image is actually one of the more reliable methods. Here are a few alternatives you might consider:

Use the Crop feature with even dimensions: In the export settings, enable Crop and manually specify even-numbered bounds. You can adjust the crop area by dragging the orange corners in the preview panel to ensure your animation fits properly within the even dimensions.
Scale down the root bone before export: If your export dimensions are too large or odd, try scaling down the root bone to a value that results in even dimensions when exported.

Post-process with ffmpeg: While not ideal, you could automate padding to even dimensions after export:

   ffmpeg -i input.mov -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2" output.mov

Regarding an official setting:

Currently, there isn't a built-in option to force even dimensions in Spine's export dialog. This feature would indeed be useful for video codec compatibility. This type of enhancement would be worth suggesting as a feature request.

For now, the Crop feature with manually specified even dimensions is probably your best official workaround, though it does require some manual adjustment to ensure your animation isn't clipped inappropriately. The dummy transparent image method you're using, while feeling like a workaround, is actually a practical solution that gives you precise control over the export bounds.

Nate

Coincidentally, 4.3.49-beta has a fix in export size, where an export with world space left edge = 0.3 and right edge = 10.3 would get captured with world space 0 to 10, 10px wide. After the fix 0 to 11 is captured, 11px wide.

It'd be interesting to know if this fixes your scenario, though crop to ensure your output size is a good idea.

aaronjheng

Thanks for your answers. What I need is a general-purpose solution. I want the exported MOV dimensions to always be even numbers.

The "Crop" option seems to require an "appropriate crop position and area," but for a generic workflow, such a thing clearly doesn’t exist, since the input from Spine can vary greatly.

As for "fix in export size," I’m also not sure whether it can guarantee that the dimensions of any exported animation will always be even. I’ll try a few spines and see how it goes.

Misaki

aaronjheng

The "Crop" option seems to require an "appropriate crop position and area," but for a generic workflow, such a thing clearly doesn’t exist, since the input from Spine can vary greatly.

I’d like to better understand what you mean here. Do you mean that you want to export a MOV file with as little margin as possible?

If you set the position and size in the Crop option, you can ensure that any Spine project file is exported at the exact same size. Since the reference X and Y positions are based on the editor’s coordinates, you should be able to reuse the same Crop option for exporting, unless the animations in a particular Spine project file are taking place at various positions far from the X/Y origin.

Exporting MOV files with excessive margins can take a very long time, so I think it would be more efficient to create several JSON files with different Crop settings. Then, for projects that can be exported at a smaller size, use one JSON file, and for projects that require a larger size, use another.

Nate

We don't have a setting for always using an even size. If you check Crop it populates with the size Spine was going to use, then you can adjust it 1px to make it even.

That is manual though. If you want a solution for any export, eg for CLI usage, you could probably write a script that exports (maybe a GIF or APNG), looks at the size, and if it's odd create an export setting JSON that crops with the right size, then export again.

aaronjheng

@Misaki
I’m using the Spine CLI to implement an automatic export-to-MOV feature. The input Spine files vary greatly, and I don’t have detailed knowledge of their specific characteristics. So I need a general configuration that can automatically ensure the exported video dimensions are even numbers.

As you mentioned in your last point, different Spine files may require different crop settings, which isn’t feasible in this case. As for the margin you mentioned, it’s not relevant here—I’m only concerned with ensuring the output dimensions are even.

Here is the JSON configuration template I’m using, in case it helps.

{
	"class": "export-mov",
	"exportType": "animation",
	"skeletonType": "single",
	"skeleton": "{{ .Skeleton }}",
	"animationType": "single",
	"animation": "{{ .Animation }}",
	"skinType": "current",
	"skinNone": false,
	"skin": null,
	"maxBounds": false,
	"renderImages": true,
	"renderBones": false,
	"renderOthers": false,
	"scale": 0,
	"fitWidth": 1920,
	"fitHeight": 1920,
	"enlarge": false,
	"background": null,
	"fps": 30,
	"lastFrame": false,
	"cropWidth": 0,
	"cropHeight": 0,
	"rangeStart": -1,
	"rangeEnd": -1,
	"outputType": "filePerAnimation",
	"animationRepeat": 1,
	"animationPause": 0,
	"encoding": "PNG",
	"quality": 0,
	"compression": 6,
	"audioEncoding": "None",
	"qualityType": "qScore",
	"pad": false,
	"msaa": 0,
	"smoothing": 8,
	"renderSelection": false,
	"cropX": 0,
	"cropY": 0,
	"warmUp": 0,
	"layerType": "frame",
	"output": "{{ .Output }}",
	"id": -1,
	"input": "{{ .Input }}",
	"open": false
}

Misaki

aaronjheng Thank you for sharing the JSON file containing your export settings. Why are cropWidth and cropHeight set to 0? If exporting at a fixed size works fine for you, you should be able to set them like this:

"cropWidth": 3000,
"cropHeight": 3000,
"cropX": -1500,
"cropY": -1000

When you specify the crop area in this way, this is what it looks like in the preview:

If you set it up this way, there may be some extra white space, but the resulting file will always be a MOV file cropped to approximately 3000x3000 pixels centered on the origin. So, if the white space isn’t an issue, I think this solution should work well.

Nate

Probably easiest is to export, the run a script that checks the size. If it's odd, run ffmpeg to resize the video up or down 1px. Ask an LLM for how to call ffmpeg.

Another thought: spine -i project.spine will tell you setup mode size, like Size: 1331.9998 x 2365.0154. If your skeleton has a background or otherwise animates inside the setup mode size, that's information could be useful. It doesn't give the position though, we'll add that.

Or of course we could pad to even dimensions. Can you provide documentation on the need for that?