Add PixelBuffer#to_bytes for zero-overhead pixel access

[querielo]

Exposes a GSI method on tl::PixelBuffer that returns the raw ARGB32 contents as a byte vector (4 bytes per pixel, row-major, top to bottom) via a single memcpy. Unlike to_png_data this skips all image encoding, which is useful when the caller just wants direct pixel data.

[klayoutmatthias]

Hi @querielo,

thanks for the PR.

I'd like to ask to include a test and maybe one small enhancement: If you add width and height as 32bit numbers at the beginning of the bitstream, it would be possible also to deserialize a PixelBuffer from that bitstream (i.e. a corresponding "from_bytes" method). Also, when you receive the bitstream, you can cross check it against the expected width and height on the receiver's end.

Is that possible?

Matthias

[querielo]

Hi @klayoutmatthias,

Thanks for the review! A few open questions:

1. Sanity limits for dimensions: A broken or malicious header could contain very large width or height value. Should we also add a maximum size limit or an overflow check before allocating memory?
2. Endianness: to_bytes writes the raw ARGB32 pixels in the native byte order (it is a direct memory copy, so there is no extra overhead). This means the format only works between systems with the same architecture. Is that OK, or would you prefer a fixed byte order for the whole format?
3. Transparency flag: The transparency flag is not stored in the byte stream. In from_bytes, I return a transparent buffer so the alpha channel is preserved. Is this OK?

[klayoutmatthias]

Hi @querielo,

Sorry for the late reply and thanks for coming back.

You're right about these points. I basically don't expect that to be a file format, but you can never know. I think a reasonable limit is 64k by 64k, but some people use the drawing feature to produce very finely resolved images. So as of now, I'd propose to limit to 64k x 64k in the reader, and "unlimited" (i.e. 32bit) in the writer. I'd throw an exception if that dimension is exceeded in the "from_bytes" method.

Regarding endianess, I'd just use native order (little endian) as AFAIK big endian is only used in network protocols, but does not play a role anymore in memory representation (at least in our domain).

And thanks for mentioning the transparency mask. Yes, that is a good idea to maintain it.

I mean, the idea is not to establish a new image format, but to enable more use cases. Please don't waste too much time on that - I just like symmetry :)

Matthias

[querielo]

@klayoutmatthias Done.

[klayoutmatthias]

Perfect! Thanks!

I'll merge the PR.

Matthias