画的匹配取决于形状，而非你选择的尺寸
大多数自定义画作资源包失败的原因，是画作的宽高比与任何槽位都不匹配。以下就是匹配的实际运作方式。
Minecraft 26.2 内置了 51 幅画，它们并不是可以随意互换的画布。每一幅都有固定的方块占位尺寸，游戏只会放置那些占位尺寸能放进它所找到的墙面空间的画。比例搞错了，你的画作就根本不会被选中。
现有的槽位形状
这 51 幅画按宽×高（以方块计）分类如下：
| 尺寸 | 数量 |
|---|---|
| 1x1 | 8 |
| 2x2 | 12 |
| 3x3 | 9 |
| 4x4 | 5 |
| 4x2 | 5 |
| 2x1 | 5 |
| 1x2 | 3 |
| 3x4 | 2 |
| 4x3 | 2 |
注意这种不对称性：有 4x2 却没有 2x4，有 1x2 却另外还有 2x1。朝向不会替你镜像处理。
你的图片为什么会被拒绝
画的纹理不会被拉伸去适应它落到的墙面。游戏会挑选一幅声明尺寸与可用空间相符的画，然后按该尺寸绘制这幅画的纹理。因此，源图片必须按照它目标槽位的精确像素尺寸来制作。
一幅 1x1 的画是 16x16 的纹理——256 像素。一幅 4x4 的画是 64x64。这些是纹理格式的定义属性，而非注册表数据，也正是你调整尺寸时真正需要的数字。
如果你提供的是一张宽幅全景图，而墙上只有 1x1 槽位空着，那就什么都不会出现。资源包没问题；放置有问题。
Java 与 Bedrock 在这里有分歧
Java 资源包通过原版画作注册表和纹理图集来定位画。Bedrock 使用自己的资源包清单结构和不同的文件夹布局。画作文件本身的 PNG 尺寸相同，但为一个版本构建的资源包无法在另一个版本中加载。请分别构建和下载。
Bedrock 这边对资源包版本管理也更严格，所以一个今天能用的资源包，可能在游戏更新后被标记为不兼容，即使没有任何画作发生变化。
实用的匹配方法
从墙面倒推，而不是从图片正推：
- 用方块测量墙面。一个 3 宽、2 高的缺口只能容纳 3x2 的画——而上面的列表里并不存在 3x2，所以这个缺口会一直空着。
- 在调整任何尺寸之前，先把源图片的宽高比对应到一个确实存在的槽位。
- 每个版本只保留一个资源包。混用 Java 和 Bedrock 的资源会做出一个两边都加载不了的资源包。
该工具会把你的上传图片匹配到形状相符的槽位，并返回制作完成的资源包，用于 Custom Paintings。