• Editor

  • bicubing sampling seems to have changed between 3.8 and 4

    영어
Related Discussions
...

It seems that images (at least in this case) appear more "jagged" then they did when packing and scaling down to 0.5x using spine 3.8.99 or lower.

I've narrowed this down to a very simple test case (a spine skeleton with a single image):

I've made a github repo with the original images, output, and the export settings for 3.8 and 4: https://github.com/jmlee2k/spine-sampling-test

Thanks for the nice reproduction case! You're right, that's really odd. I traced it down to native code and we definitely tell it to use bicubic, but the output looks like bilinear. We'll have to dig deeper. To make sure we don't lose the bug, I've created an issue:
https://github.com/EsotericSoftware/spine-editor/issues/606

Thanks for looking into this. I've verified that this happens in 4.0.07, which is the oldest 4.x version I can launch.

I know it's a stretch, but do you have any ideas how we can use spine 4 with bicubic sampling until the upstream bug is fixed?

I'm afraid it's not possible, the 4.0 versions with the bicubic sampling do something wrong. You could use an older version to do the atlas packing, either 4.0 before the bug or even 3.8.99. You'd still export the data with the latest, just pack atlases with the old version. Packing from the command line may be handy, you can specify the version with eg -u 3.8.99. Sorry for the trouble!

Thanks, I figured as much. Is there a way to run 4.x versions earlier than 4.0.07 so I can see if there's a 4.x version without the bug?

Ah, sorry there isn't. Some older releases had significant issues and are no longer available.

Ok, we'll probably stick with 3.8.99 until the bug is fixed because exporting atlases in one ver and data in another will be too complex for our workflow. I appreciate the help!

We've fixed it in 4.0.38 by scaling the image without depending on the broken upstream library.

I can confirm that the images look as expected in 4.0.38, HUGE thanks!

As a minor side note, when choosing "auto" for the resampling mode, the image looks the same as 4.0.37, but explicitly choosing "Bicubic" fixes the issue.

Ah, you're right. The fun never ends! We'll fix up auto too. 🙂

"auto" works great on 4.0.39, thanks again!

I Just noticed that "auto" is no longer an option when using the spine UI, but using the CLI with "auto" in the export settings JSON results in bicubic. Is "auto" still valid to use in export settings files?

We'll change our export settings to explicitly use bicubic for clarity, but I was just curious.

Thanks for confirming!

We remove auto and progressive bilinear:

All scaling is now progressive when downscaling (meaning it is scaled down by halves multiple times until the desired size is reached), which gives better quality. No one wants worse quality, right? So we don't need the setting. 🙂

Auto used to choose between bicubic one-step upscaling or progressive bilinear downscaling. Now that we have progressive bicubic downscaling the choice is just bilinear or bicubic, the auto setting isn't needed.

You can still specify the old values, eg via the CLI, but auto gives bicubic and progressive bilinear gives bilinear.

Makes sense, thanks for the explanation and thanks again for resolving this so quickly!