Specifying the color space for manipulation

[kimikage]

(Perhaps, as @johnnychen94 knows,) I am currently rethinking the definition of default color spaces for YIQ and YCbCr in ColorTypes.jl and Colors.jl. (cf. JuliaGraphics/Colors.jl#453, JuliaGraphics/ColorTypes.jl#250)

AFAIK, this is the only package that explicitly uses YIQ. This package is indifferent about the gamma of YIQ color space, even though it is designed to manipulate the contrast. 😅

If the implementation of the conversion from RGB etc. to YIQ is slightly changed, will there be any inconvenience?

In any case, for compatibility and convenience reasons, I think it might be a good idea to allow the user to explicitly specify the color space in which to manipulate the contrast.
So, what about adding the following getter and setter to the keyword arguments of the API?

getluma(c::Colorant)
setluma(c::Colorant, luma::Real)

Also, what about switching the default implementation of the getters and setters depending on the color type?
For example:

color types	luma-like value
(fallback)	YIQ(c).y
Gray	gray(c)
HSV	c.v
HSL	c.l
HSI	c.i
Lab/Luv	c.l / 100
XYZ/xyY	xyY(c).Y

Of course, the feature should be realized with outside of this package by using MappedArray or something. My main aim is to reduce the impact of breaking changes in ColorTypes.jl and Colors.jl.

[johnnychen94]

If the implementation of the conversion from RGB etc. to YIQ is slightly changed, will there be any inconvenience?

I think ImageConstractAdjustment can live with this change as an enhancement instead of a breaking change.

In any case, for compatibility and convenience reasons, I think it might be a good idea to allow the user to explicitly specify the color space in which to manipulate the contrast.

A hard call. I think users can just manually map their color3 images to a gray version with whatever ops they like, and pass the gray version data toadjust_histogram

[kimikage]

I think ImageConstractAdjustment can live with this change as an enhancement instead of a breaking change.

My concern is that changing the color spaces in ColorTypes.jl and Colors.jl does not involve the API change, so the results may change without the user's notice, even if the version of ImageContrastAdjustment does not change.
Therefore, it is important not to confuse the versions of Colors.jl before and after the change. However, this package is not directly dependent on Colors.jl.

Of course, since this package is in pre-v1.0, it may be enough to write a warning statement that the persistence of the results is not guaranteed. 😝

[zygmuntszpak]

The colour contrast enhancement in this package has not been thought through carefully. I know that proper colour image processing is its own beast, and I just haven't gotten around to studying the literature sufficiently to really understand the subtleties. I chose to always manipulate the Y channel of the YIQ colour space when given a colour image because I wanted to have some default and consistent way of applying the various algorithms (e.g. histogram equalization, contrast stretching, gamma correction etc.) to colour images. The application I had in mind was having some way of manipulating the contrast of colour images in the context of data augmentation for machine learning applications. The current implementation probably hasn't been thought through carefully enough to really facilitate colour image science applications where all the issues of white points, references etc. are properly resolved.

If the implementation of the conversion from RGB etc. to YIQ is slightly changed, will there be any inconvenience?

Personally, I would not be inconvenienced but it is possible that someone downstream is using this for some ML image application as part of their feature processing, and their classifier might be affected because the extracted features have now changed. Without some kind of warning, they would probably never guess that it is because of a change to the YIQ conversion.

In any case, for compatibility and convenience reasons, I think it might be a good idea to allow the user to explicitly specify the color space in which to manipulate the contrast.

I haven't studied the Color and ColorType packages in detail, but are you suggesting that users should also be free to specify the default color space for YIQ? I noticed in one of your links above that you discussed things such as "sRGB w/ setup" and "NTSC (1953) w/o setup" for the definition of YIQ.

When you made the list of luma like values, are you suggesting for example that if a user passes in an HSL image, then the contrast should be manipulated on the L channel and we shouldn't convert the HSL to YIQ, apply the contrast manipulation on Y, and then map back to HSL?

[kimikage]

Thanks for your response.

Without some kind of warning, they would probably never guess that it is because of a change to the YIQ conversion.

Agreed. ColorTypes.jl and Colors.jl are at a low level, so it's hard to communicate the message to the end users without annoying warnings.

are you suggesting that users should also be free to specify the default color space for YIQ?

That's not quite right. A few years ago, I was exploring ways to allow users to specify various color spaces and conversion methods, but concluded that the context that had to be managed was too large for Colors.jl and its users. Perhaps we need a new package like ColorManagement.jl.

I don't want to create a type like YIQ{Float32, :SMPTE_C, :NoSetup, :Scale1, :ChromaCenter0} 😅, so I came up with the idea that the users should be responsible for the color spaces they use. Currently, the ColorTypes.jl's README.md declares that the RGB type is for sRGB color space. What I'm trying to do with the PR is to allow the users to use RGB for any RGB color space they want, in exchange for the responsibility.

sRGB will be the default color space for the RGB type, but the default color space for YIQ is "not documented" at the moment. I can't say that the current implementation is wrong, but I can't say that it follows the NTSC standard exactly either. Therefore, if we are to keep the current implementation for YIQ, we need to identify how it differs from the standard. If we change the implementation, we need to assess the impact.

the contrast should be manipulated on the L channel and we shouldn't convert the HSL to YIQ, apply the contrast manipulation on Y, and then map back to HSL?

I don't think it "should" always be done that way, but I do think that in color image processing, when the user is using a color space other than RGB, it might be better to respect the intention. This is somewhat debatable, but at least we can say that most of the target color images are in RGB, and other color spaces are not very important. 😂