Thanks to @Ablu for tracking down the following commit which implements part of this functionality:

9b55907

Here is clean code who get custom property in tileset file : 5a97ea6

Example

<tile id="0">
    <image width="110" height="70" source="tiles/0.png"/>
    <properties>
        <property name="originalX" value="56"/>
        <property name="originalY" value="28"/>
    </properties>
</tile>

Is this possible yet in Tiled?

@elvisish Nobody has worked to integrate this feature so far.

The commit I linked to in my previous comment implements part of the needed functionality. What is missing is:

• Allow the offset to be changed in the UI. An obvious choice is to add it to the Properties view when you select a tile. But since this is essentially about setting an origin, some graphical and more intuitive way could be implemented as well (though I currently don't see a good place for this in the UI).

• If individual tiles could be offset by some amount, this needs to be taken into account when determining which part of a tile layer to render within a certain rectangle of the viewport. You could look into how this is done for the existing tileset-wide tile offset and calculate the per-tile offsets into it.

Issue came up on the forum.

Requested again on the forum.

Hi,
Sorry to bring this back again :D (I already reported it here #1958 )

I see that both issues was closed, is there any plans to support this at some point, or is there any workaround for it ? (like setting the offests manually in the image tile) ?

sorry for bothering you again with this 😄

oh sorry I just saw that it's available already.

it was just not obvious to show the tileset properties once we add images to it.

please ignore my previous comment :)

@alaa-eddine Right, it's just not for individual tiles (hence this issue is still open, actually). But if the tileset-wide offset works for you, that's great!

Just leaving a comment to reference my request for image offsets in the isometric collision editor (@bjorn says it is related to this issue) https://discourse.mapeditor.org/t/image-offset-in-isometric-collision-editor/4997

Just to add another voice, I'll need this too. Given that this issue seems to surface fairly frequently and is quite fundamental (almost all game engines have the notion of per-object origin), may I be so bold to suggest making this a priority? The editor is a fantastic job otherwise right now -- I find myself very satisfied but regret that this small thing can be quite a dealbreaker.

I'd also love if this were possible. Big issue in trying to import maps into Tiled as of the moment for me

It would be great if there were per-tile offsets similar to how godot/unity allows.

I would also like to see this feature!

gimme

Drawing offsets rather than origins would be helpful for iso/hex tilesheets with depth where the tiles aren't aligned consistently, e.g. when they're all centred within their bounding boxes, rather than having their bottoms all line up.

My thoughts on this topic, and why I don't like the direction the current PR is going:

I see two distinct problems here:

• The original issue: adjusting the render position of tiles in Tile Layers so that they're aligned as the user needs.
• The more recent one: setting an origin on Tile Objects with more precision than the Object Alignment provides.

I am not confident that both issues can be solved with the same feature, which seems to be the current goal, even though in most cases, a tile is either meant for use in Tile Layers or as Objects, and it's therefore not common to need distinct values for the offset and for the origin. Even though there's little overlap, these are still distinct needs with distinct purposes.

Tiled currently conflates two distinct aspects of Objects with associated sprites/tiles in game engines: the Object's origin point, and the drawing offset of the sprite relative to the Object. In engines, it's quite common that the Object is not the same size as the sprite representing it, and in Tiled, this is currently only possible to represent with Tile Collision, but the Tile Collision does not affect snapping, and it's not possible to view Tile Object collisions without also viewing Tile Layer collisions.
The current handling of drawing offset for Tile Objects is also inconsistent with Tile Layers: in tile layers, it's merely a cosmetic offset that doesn't affect the underlying position of the cell and the way you select the cell, but for Tile Objects, it affects the actual position of the object and affects how you select it, due to the conflation described above.

I think that the solution to this issue should be as stated in the original post: per-tile drawing offset.

Tile Objects could use a bit of rethinking to better match the roles they tend to play in engines: origin should be an object property for all objects, not just Tile Objects, and Tiles should be treated more like sprites drawn on top of an underlying Rectangle rather than the object themselves - they should have their own scale factors independent of the object size as requested in #3129 (but could default to "match object size", and perhaps there could be a per-tile default scale setting), and they should be offset from the object according to their Drawing Offset, but when selecting the object, it should be the object's shape/bounding box that is highlighted, not the tile's bounding box.
Per-Object (not per-Tile) origin would also solve #560 and make rotations more convenient in general.
If done this way, Tiles can still have a default object origin assigned to them as a convenience, so that when Objects are made with those tiles, they inherit that object origin, since Objects sharing Tiles tend to share the same origin. The origin could still be overridden on a per-Object basis, so two objects using the same tile can have different origins if the user wants.
Perhaps it could even be possible to make Tiles something you can attach to any shape, rather than a dedicated Object type :]

While opting for a much simpler tile rendering logic, we decided to have a fixed size for our hexagonal tiles, because of that, we need to set a rendering offset on our tileset, otherwise the grid would be misaligned. The snapping feature tho only takes the origin into account, since we need a custom origin for our tiles because they are bigger then the actual hexagon, the snapping feature is ultimately broken. Instead of predefined dropdown, the Object Alignment property should accept custom values too.

I've unfortunately just ran into this issue myself, I am in the midst of reworking some core engine code in order to transition away from basic Tile maps to a more Entity driven approach, and the "collection of images" tileset plays into this really well... until I have something like a lamp post that sticks out a bit at the edges. For the moment I am going to leverage properties and have the Engine render pipeline handle it, but it would be really nice if I could get Tiled to display things as they appear in game with this feature.

This ticket seems to be targeted at Tile objects, but I think this would be a valuable feature for the "multiple image" tilesets on individual images too. For me, who has statues and lamp-posts and things that stick out horizontally over the edges of adjacent tiles anyway.

Edit: Worth mentioning I forsee a complication with the collision boxes when a render offset is present... I think having the collision bounds also be affected by these offsets makes sense to me and is the obvious thing to do but I thought it best to mention it in case others have good reasons why that is a bad idea ;)