BUG: 3D Tokens don't keep their proportion XML data on Client side.

[Vass_Dts]

It is possible that prior to the update, images were scaled differently. I don't recall that being my experience but it doesn't really matter. And the reason it doesn't matter is that, even if FG correctly scaled an image sans XML (and I'm with you, it should), it would still scale it inside a 5ftx5ft square (for a medium size creature). But there are creatures that are taller than 5 ft. Most humanoids are taller than 5 ft. Or creatures that are wider than 5 ft. Particularly in larger sizes, you get far greater variation in creature dimensions. Without an xml, the images would always be scaled inside a 5x5 or 10x10 or 15x15 square (using 5e standard size definitions). The XML allows an image to go beyond those constraints. To have a humanoid that is 6'1" but that is medium and stands of a 5x5 square. That's why you need the XML data. Because even if it correctly scales an image sans XML in the way you describe it did, that token will still look too short compared to all the other tokens that are already baked in FGU (everything inside the Monster Manual for instance).

My personal objection to all this is that to add the XML, you need to use an external tool--and one that is not easy to find if you don't know where to look. Ideally, it should be part of FG's interface (perhaps part of the Assets manager). But unfortunately for you and I, the majority of users use premade adventures, tokens, monsters, etc. Many of them don't even know how to remove the background from an image to have a png or webp image with transparency in order to make such a token. Which means that, being a small group, SW has to pick their battles (or more accurately, in what order they should do things) and that means that I don't know when and if they are going to fold the XML metadata builder inside FG itself (emphasis on "don't know." They might actually intend to do that next week. Or next year. Or never.)

Me personally, I got the applet. I know how to use it. It doesn't really matter for my use-case. But I still think it would be ideal for all users, if it was part of the FGU's interface.

[RosenMcStern]

I'm not advocating removal of the configuration, just that it adopts a reasonable default when the metadata is not there. And it could very well assume that the total height of the picture is equivalent to 6 feet, it would fit most pictures you find on the internet and make them immediately usable as tokens. 4.5.0 did it, so it is possible. Of course you would still need to add metadata to some tokens, for instance the oversize ones and those with long spears, but for most tokens usable as PC images there is little or no need to use metadata.

[Vass_Dts]

I understood what you suggested. And I agreed with you on that. I'm just saying that's good only as a temporary, on-the-fly solution for when you add tokens without an XML. So that they look at least a bit decent until you add the XML. I'm just explaining that the key-word is "until" you add the XML. You can't not add the XML and have it look good--or at least--equally good as the ones that have the XML.

And the assumption that every medium creature is 6 feet tall is an arbitrary generalization. Sans XML, we both are of the opinion that the software should scale an image in the confines of a 5x5 square. From your description, that's what I gathered it did originally. What it does now, is that it stretches the image on all sides to fill the 5x5 square. That's why the tokens look squashed instead of just shorter that the rest.

[pindercarl]

Will the patch also solve the problem of "squashing" 3D tokens when there is no XML? Version 4.5.0 correctly calculated width and height of the picture, 4.5.1 does not. It resizes the width to predefined proportions. Very annoying.

This issue has been identified and should be fixed in the next release update.