-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Primitive Color Type for .NET Core #14825
Comments
How is the primitive going it be used? Which graphics technologies will expose or consume it? |
That's actually what we are asking you. Many people have used different definitions of color to accomplish different things. We would like to know what worked and what didn't in different scenarios. We would like to bring over the legacy primitive color type from System.Drawing, but we also want to be aware of scenarios that may require a different structure. |
This is the https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.color.aspx They have other great primitive types as well, e.g. In addition to that, from my limited experience:
|
I guess it makes sense to link the previous discussion: https://github.com/dotnet/corefx/issues/1563 |
Here's the guts of a Color struct I've been working on. It's pretty handy. https://github.com/JimBobSquarePants/ImageSharp/blob/master/src/ImageSharp/Colors/Color.cs |
@kendrahavens is there something here that isn't satisfied by the |
|
Okay, we need an api proposal to review. |
There's more to a single color struct that meets the eye. Whatever would be designed would have to interop well with existing libraries and be performant. TBH I'm not sure it is something that should exist on its own outwith a graphics library. |
@alexperovich Well, our whole graphics discussion was torn between designing something new and amazing, but that can also support the legacy type. We decided to start supporting the legacy type first and if designs came up for new and amazing things we could think about them later. |
Well if we need a new color struct, should the usage of the old one in places like System.Windows.Forms properties in some of it’s controls/classes and functions in like System.Drawing.Image/Bitmap/Graphics also need to use this. Although in a way that does not break backwards compatibility. Like maybe have the new derive from the old? |
Color math should ideally be done with Floats also avoid the problem of clipping, as colors above 1 still work fine. Even if they clip when displayed, if the brightness is reduced for the whole image, the brightness differences in bright areas is preserved when using floats. Floats are also more friendly to the user. It's easier to understand that "0.5" is 50% strength than "127". Or was it "128"? I hope you get my point. Therefore, for all of the above reasons, I propose that a type simply called Of course, some people may wish to define a color with Another option for the above is that there could be a separate |
Having a standard primitive 3 or 4 byte RGB value type for dealing with simple peripherals such LEDs and LCD panels would be helpful. It should be independent of System.Drawing or other specific UI technology. |
If this were to be added, where would it be added to? |
that makes sense to me. |
💭 Having only glanced at this conversation, I feel like it'd be simply too much work, even conceptually, to unify all the scenarios, lest we end up with:
Conversions would be available between any of these in either direction, with the documented caveat that they'll be lossy, except probably when going from either of the bottom two to the first one. |
That XKCD is right on. A completely agnostic
These issues become even more salient in light of the fact that display hardware is improving to the point that the sRGB gamut (which was defined to match the output of CRT displays) is no longer enough. Display P3 is already establishing itself as a new standard, and that means the old assumption that sRGB is the one true RGB is no longer safe. |
@Joe4evr It definitely can be useful to have multiple Color representations, though I would make a few tweaks to your suggestion.
I don't particularly care about a direct HSV representation. We can just provide @saucecontrol One of the advantages of floating-point color is that you can work with values outside the normal sRGB range if desired. Normal values are from 0 to 1, but you can easily have a value of 1.5, though this can't be converted to a "traditional" |
I would believe that the appropriate thing to do would be to make the color structs generic (e.g. Likewise, you can't have a low overhead "general-purpose" Anything else requires you to carry additional state somewhere which can make low-level/high-perf cases not as worthwhile (due to additional conversion/copying overhead or additional space taken in memory). |
What you might ultimately end up with then is a |
There's no valid use case IMO for a type without the alpha channel. If you don't want alpha, you can either ignore it, or we can reserve a special value like What specifically can't be done with a general-purpose |
No single-line of code way. It would be supported the same way as
Yup, generic specialization allows this, as mentioned above. DXGI alone defines about ~100-130ish color formats, all of which are used in varying contexts: https://docs.microsoft.com/en-us/windows/desktop/api/dxgiformat/ne-dxgiformat-dxgi_format. These include half-precision, single-precision, 8-bit, 16-bit, and 32-bit integer components from a glance. Other graphics libraries sometimes define additional ones. Having several general-purpose generic types allow you to satisfy/expose all of those formats with little overall overhead as compared to special-casing each one with a separate type.
There are a plethora of formats which have no support for any alpha channel. Many formats also allow or use pre-multiplied alpha components rather than requiring or allowing an alpha channel at all.
That is the point of exposing a few select generic, but component sized
It may take more space than is required and may not be possible to blit to/from the target format. |
32 bit per channel is too much space. The idea of having ranges exceding 0. to 1. goes along with specific encodings and color spaces (e.g. scRGB). Doesn't make sense with more standard color profiles. |
I don't think there is an advantage to adding this that exceeds the development costs. |
I made a PR that implements a new The PR has been closed due to the API not being approved, so... consider this comment a proposal. Here's direct links to my proposed Color.cs, Colors.cs, Color8.cs, Colors8.cs, and ColorUtils.cs. The two types are Another commonly requested feature was a Color type that uses HSV. Against @Joe4evr's advice, I don't think this is worth adding as its own type, but To make this, I used and/or referenced several existing Color types:
A few important notes:
|
Any update on this? .NET Core 3.1 has been out for awhile, and .NET 5 is intended to be released at the end of this year, so this seems like the appropriate time to add I have a branch here, and a closed PR with more information here. I encourage any .NET Core members to take this code and get it merged and conforming to whatever standards you have, or please let me know what I can do to help or what I need to change about it to get it merged. |
As was pointed out in your PR that was closed, the first step is a concrete API proposal. See this doc for the process and examples of how to proceed: https://github.com/dotnet/runtime/blob/master/docs/project/api-review-process.md |
Closing this as I don't think it is super actionable. As indicated by dev's extremely familiar with the area (such as @JimBobSquarePants and @rickbrew) here and on related issues such as #32418, this space is extremely scenario specific. To essentially reiterate what was said here: #32418 (comment), I think the only actionable thing would be to add some "common algorithms" for specific scenarios where applicable. It might be reasonable to then expose some algorithms that operate on a |
Primitive Color Type for .NET Core
The previous discussion of primitives showed that color discussion should expand into a separate issue.
The primitive discussion was started because many customers wanted to move to the .NET Core, but were blocked by the lack of System.Drawing primitives there. There was much discussion and internal debate over defining Point, Rect, and Size and much of that was fueled by scenarios that you guys cited in the previous primitives issue. (Thank you!) Here we are looking for additional scenarios to discuss the advantages of creating a new Color type for the cross-platform .NET Core Graphics API. Feel free to repost your two cents from the previous primitives issue. Thanks for your input!
Topics of Interest: (This is where providing scenarios would be awesome)
Limit Scope: KnownColors will not be brought over as they don’t always translate well into the cross-platform world depending on the hardware so let’s focus our discussion on defining the Color object for now.
The text was updated successfully, but these errors were encountered: