Refactor: RGBAPixel and LABAPixel to use composition with a generic AlphaPixel wrapper

[Ryan-Millard]

Hi @Krasner, I'm not sure about how to approach this issue, so I am starting this with a discussion to find the cleanest possible way to make a reusable struct for this purpose. Below is the issue body I am proposing. Please let me know your thoughts.

---

During the discussion in PR #234, it was noted that RGBAPixel and LABAPixel currently inherit from RGBPixel and LABPixel. This causes two main issues:

1. Memory layout concerns:

   • Arrays of pixels are used heavily in low-level image processing.
   • Inheriting from a base struct can introduce compiler-specific padding, breaking memory-mapped arrays and predictable struct sizes.

2. Conceptual clarity:

   • Alpha channels or extra LAB channels represent components of a pixel, not fundamentally new pixel types.
   • Composition (has-a) better reflects this relationship than inheritance (is-a).

Proposed Refactor

1. Introduce a generic AlphaPixel wrapper

This wrapper can wrap any pixel type and add an alpha channel. Example:

template <typename PixelT>
struct AlphaPixel {
    PixelT base;   // the underlying pixel (RGB, LAB, etc.)
    typename PixelT::value_type alpha;

    // Constructors
    AlphaPixel(const PixelT& p = PixelT{}, typename PixelT::value_type a = 255)
        : base(p), alpha(a) {}

    // Equality operators
    bool operator==(const AlphaPixel& other) const {
        return base == other.base && alpha == other.alpha;
    }
    bool operator!=(const AlphaPixel& other) const {
        return !(*this == other);
    }

    // Convenience setters
    void setAlpha(typename PixelT::value_type a) { alpha = a; }
};

• RGBAPixel becomes using RGBAPixel = AlphaPixel<RGBPixel<NumberT>>;
• LABAPixel becomes using LABAPixel = AlphaPixel<LABPixel<NumberT>>;

This allows a single, reusable pattern for any “pixel + alpha” type.

2. Update Image template

Currently, Image requires:

static_assert(
  std::is_base_of_v<Pixel<typename PixelT::value_type>, PixelT>,
  "Image<PixelT>: PixelT must derive from Pixel<NumberT>"
);

After refactor:

• Change to allow any type that contains a Pixel member or satisfies a “pixel-like” trait.
• Example trait:

template <typename T>
struct is_pixel_like {
    static constexpr bool value = requires(T p) { p.base; };
};

Or C++20 concept:

template <typename T>
concept PixelLike = requires(T p) { p.base; };

3. Update PixelConverter usage

Converter functions wrap the base pixel inside AlphaPixel:

template <typename NumberT>
inline AlphaPixel<RGBPixel<NumberT>> convertRGBA(const uint8_t *p) {
    return AlphaPixel<RGBPixel<NumberT>>{
        RGBPixel<NumberT>{static_cast<NumberT>(p[0]),
                           static_cast<NumberT>(p[1]),
                           static_cast<NumberT>(p[2])},
        static_cast<NumberT>(p[3])
    };
}

• loadFromBuffer() works unchanged.
• The extra alpha channel is now a member, guaranteeing predictable memory layout.

Benefits

• Predictable memory layout for arrays of pixels.
• Clearer conceptual model (RGBAPixel and LABAPixel have an alpha, not are an alpha pixel).
• Single, reusable AlphaPixel struct avoids code duplication.
• Compatible with existing PixelConverter and Image system with minor updates.

References:

• Discussion in PR #234

[Krasner]

or we can always have an alpha in every color space. right now alpha is not being used so really we are just bookkeeping.
RGB is just RGBA with alpha = 255
LAB is just LABA with alpha = 255.0

[Ryan-Millard]

What if we start accounting for alpha in our future implementations? Currently, an image that has alpha=0 in certain regions gets those regions back with alpha=255, which could be annoying if you have an image like the below:

I would personally get annoyed as a user if I wanted there to be no background.

[Krasner]

yeah we really should keep track of alpha better.
for example in kmeans it is hard coded to 255

out_data[i * 4 + 3] = 255;

in Node we don't even track it - RGBXY

[Ryan-Millard]

@Krasner, I'm sorry for not replying - I didn't get a notification for this. GitHub is terrible sometimes.😢

Alpha doesn't really matter when converting to an SVG, though. If we do eventually start clustering based on alpha as, it may be important, but setting alpha to 255 in K-Means is more of a way to uniformly visualize the output. I'm not entirely sure what we should do here.