Change word `component` to `subpixel`.

[ripytide]

Should we change the word component to subpixel throughout the library? It is both shorter and more recognizable/understandable in my opinion.

This also goes nicely with a possible Pixel trait discussed in https://github.com/kornelski/rust-rgb/issues/39#issuecomment-835298062

[kornelski]

Subpixel is more related to a physical display, rather than the color model. For RGB it may seem the same thing, but for example, I haven't heard "alpha" called a subpixel. Pixels (or samples) in the YUV or YCbCr color spaces are using the term components or channels, and not subpixels.

And in channel vs component, channel could be understood as a planar pixel layout, and this crate is specifically for the interleaved pixel layout.

[ripytide]

Good point.

On the other hand Subpixel is already used somewhat from the image crate in their Pixel trait as an associated type so we'd be improving consistency with the rest of the crate ecosystem which is the main goal with this crate.

[kornelski]

It looks more a mistake in the image crate - they use CHANNEL_COUNT and channel() to work with "Subixels".

[ripytide]

And yet their pixel types like Rgba use interleaved format which contradicts your channels being planar layout logic, very confusing all round. I wish there was a more standard word here that was also shorter and less generic-sounding than component

[kornelski]

It could be worse. In the era of CRT monitors they were called "gun" (as in electron gun), "VGA has 6 bits per gun".

[ripytide]

According to the Pixel wikipedia page industries also refer to "Subpixels" as just "Pixels":

In display industry terminology, subpixels are often referred to as pixels, as they are the basic addressable elements in a viewpoint of hardware, and hence pixel circuits rather than subpixel circuits is used.

[kornelski]

That's from hardware perspective. In software they're samples

https://en.m.wikipedia.org/wiki/Sample_(graphics)

but that term isn't great either as it carries baggage of signal processing, and odd concepts like offset (location that has been sampled which is not always the center of the pixel)

[ripytide]

The word "component" is sadly also not free from confusion: https://en.wikipedia.org/wiki/Component_video. :frowning_face:

[kornelski]

Component video is named correctly, and that's the same kind of component as pixel components.

[ripytide]

Does that mean that alpha is not considered a "component" of a pixel?

[ripytide]

We could do both if we are making two traits:

pub trait Pixel {
    fn subpixels(&self) -> [T; 3];
}

pub trait AlphaPixel {
    fn components(&self) -> [T; 4];
}

This would then fit with the alpha is not a subpixel logic while still using the "component` word when alpha is involved?

[kornelski]

No. Let me be clear: subpixel is an incorrect term for this, and use of this term in the image crate is an error. It describes hardware. Terms like "subpixel rendering" are dependent on physical properties of the hardware they target. This term would make sense in a display driver, but this crate is more abstract than that. There's also "sub-pixel precision" (sub-pel), but this refers to rendering methods, not the channels/components.

RGB as a color model uses components. The term channel could also be okay, component and channel are often used interchangeably, except that channel is more strongly associated with a planar color layout where each channel is a separate monochrome image with intensities for a color component.

[ripytide]

Okay that makes sense to me. I'll no longer use the word "subpixel".

I'll experiment a bit more with the two-trait method, though I suspect we'll still need two different names for returning arrays of non-alpha components and alpha-inclusive components.