Add ToHex method to Argb32.

[lindexi]

We can find the ToHex in Rgba32, but not found in Argb32

[antonfirsov]

You can do argb.ToRgba32().ToHex() as a workaround. However, implementing it should be trivial; if you are interested, feel free to open a PR, we will be more than happy to take it :)

[JimBobSquarePants]

Thanks for the suggestion. However, I don’t think adding ToHex() to Argb32 (or keeping it on Rgba32, for that matter) is the right approach.

Pixel formats like Argb32, Rgba32, etc. are storage representations, not semantic color types. They describe channel layout in memory, and hex string formats do not map cleanly to that. Hexadecimal color strings are a semantic representation of color, typically in a standard order like #AARRGGBB (for XAML/Microsoft platforms) or #RRGGBBAA (for CSS/Web). If we add ToHex() to every pixel type, we’re implying that the pixel’s memory layout defines the hex format, which isn’t true and will confuse users.

The fact that Rgba32.ToHex() currently outputs RRGGBBAA, reflecting the field order of the struct, already highlights this mismatch. This is misleading because most people expect hex strings to follow common markup conventions, not match a raw memory layout. I’m planning to remove these methods from the pixel types entirely and keep hex output on Color, where we can define consistent semantic formats.

The right approach is to:

• Leave parsing in the pixel types, since you often want to construct a pixel from raw hex input (especially for tests and image manipulation).

• Centralize formatting/export on Color, which will support both formats:

  • #AARRGGBB, for XAML/Microsoft compatibility.
  • #RRGGBBAA, for CSS/Web compatibility.

This keeps responsibilities clear: pixel types are for storage and manipulation, while Color is for semantic use cases like serialization, formatting, and interop.

If someone needs a raw hex dump of a pixel’s memory layout, they can build that explicitly for debugging, but it’s not something we should expose as a general-purpose API.

Happy to discuss further if anyone sees a strong reason to take a different approach, but this separation of concerns is the most maintainable and least surprising design.

[JimBobSquarePants]

I've actually opened #2964 with the changes I believe should be implemented to provide support.

[antonfirsov]

The fact that Rgba32.ToHex() currently outputs RRGGBBAA, reflecting the field order of the struct, already highlights this mismatch.

I haven't thought about this aspect. It makes total sense!

Leave parsing in the pixel types

If we remove formatting, IMO it's problematic to keep the parsing, but I see you removed both in the end.

The only con for removing existing stuff from Rgba32 is compatibility, I can imagine many users took dependency on that method. I know we are on the path of breaking things in V4, but it always makes me slightly worried.

[antonfirsov]

Maybe we can consider adding extension methods for IPixel<T> on top of the new Color API-s (using the same parameters & semantics)?

[JimBobSquarePants]

Adding them to IPixel<T> would be problematic in that they then ambiguate the relationship between memory and hex layout.

Leave parsing in the pixel types

I thought I had corrected that. It was very late when I wrote the statement. Color should be our point of entry.

I'm happy with the shape of the API I introduced with #2964