Struct Cicp 

pub struct Cicp {
    pub primaries: CicpColorPrimaries,
    pub transfer: CicpTransferCharacteristics,
    pub matrix: CicpMatrixCoefficients,
    pub full_range: CicpVideoFullRangeFlag,
}

Reference: https://www.itu.int/rec/T-REC-H.273-202407-I/en (V4)

Fields

primaries: CicpColorPrimaries

Defines the exact color of red, green, blue primary colors.

transfer: CicpTransferCharacteristics

The electro-optical transfer function (EOTF) that maps color components to linear values.

matrix: CicpMatrixCoefficients

A matrix between linear values and primary color representation.

For an RGB space this is the identity matrix.

full_range: CicpVideoFullRangeFlag

Whether the color components use all bits of the encoded values, or have headroom.

For compute purposes, image only supports CicpVideoFullRangeFlag::FullRange and you get errors when trying to pass a non-full-range color profile to transform APIs such as DynamicImage::apply_color_space or CicpTransform::new.

Implementations

impl Cicp

pub const SRGB: Self

The sRGB color space, BT.709 transfer function and D65 whitepoint.

pub const SRGB_LINEAR: Self

SRGB primaries and whitepoint with linear samples.

pub const DISPLAY_P3: Self

The Display-P3 color space, a wide-gamut choice with SMPTE RP 432-2 primaries.

Note that this modern Display P3 uses a D65 whitepoint. Use the primaries SmpteRp431 for the previous standard. The advantage of the new standard is the color system shares its whitepoint with sRGB and BT.2020.

fn to_moxcms_compute_profile(self) -> Option<ColorProfile>

Get an compute representation of an ICC profile for RGB.

Note you should not be using this profile for export in a file, as discussed below.

This is straightforward for Rgb and RgbA representations.

Our luma models a Y component of a YCbCr color space. It turns out that ICC V4 does not support pure Luma in any other whitepoint apart from D50 (the native profile connection space). The use of a grayTRC does not take the chromatic adaptation matrix into account. Of course we can encode the adaptation into the TRC as a coefficient, the Y component of the product of the whitepoint adaptation matrix inverse and the pcs’s whitepoint XYZ, but that is only correct for gray -> gray conversion (and that coefficient should generally be 1).

Hence we use a YCbCr. The data->pcs path could be modelled by (“M” curves, matrix, “B” curves) where B curves or M curves are all the identity, depending on whether constant or non-constant luma is in use. This is a subset of the capabilities that a lutAToBType allows. Unfortunately, this is not implemented in moxcms yet and for efficiency we would like to have a masked create_transform_* in which the CbCr channels are discarded / assumed 0 instead of them being in memory. Due to this special case and for supporting conversions between sample types, we implement said promotion as part of conversion to Rgba32F in this crate.

For export to file, it would arguably correct to use a carefully crafted gray profile which we may implement in another function. That is, we could setup a tone reproduction curve which maps each sample value (which ICC regards as D50) into XYZ D50 in such a way that it appears with the correct D50 luminance that we would get if we had used the conversion unders its true input whitepoint. The resulting color has a slightly wrong chroma as it is linearly dependent on D50 instead, but it’s brightness would be correctly presented. At least for perceptual intent this might be alright.

pub(crate) const fn qualify_stability(&self) -> bool

Whether we have invested enough testing to ensure that color values can be assumed to be stable and correspond to an intended effect, in particular if there even is a well-defined meaning to these color spaces.

For instance, our current code for the ‘luma’ equivalent space assumes that the color space has a shared transfer function for all its color components. Also the judgment should not depend on whether we can represent the profile in moxcms but rather if we understand the profile well enough so that conversion implemented through another library can be derived. (Consider the case of a builtin transform-while-encoding that may be more performant for a format that does not support CICP or ICC profiles.)

A stable profile should also have derived_luminance implemented.

pub(crate) const fn into_rgb(self) -> CicpRgb

Discard matrix and range information.

pub(crate) fn try_into_rgb(self) -> Result<CicpRgb, ImageError>

Trait Implementations

impl Clone for Cicp

fn clone(&self) -> Cicp

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Cicp

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl From<CicpRgb> for Cicp

fn from(cicp: CicpRgb) -> Self

Converts to this type from the input type.

impl Hash for Cicp

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl PartialEq for Cicp

fn eq(&self, other: &Cicp) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for Cicp

impl Eq for Cicp

impl StructuralPartialEq for Cicp