Skip to content

Add footnote about colors being in-gamut (i.e. components in [0,1])#208

Closed
portsmouth wants to merge 32 commits intoAcademySoftwareFoundation:dev_1.1.1from
portsmouth:color_gamut
Closed

Add footnote about colors being in-gamut (i.e. components in [0,1])#208
portsmouth wants to merge 32 commits intoAcademySoftwareFoundation:dev_1.1.1from
portsmouth:color_gamut

Conversation

@portsmouth
Copy link
Copy Markdown
Contributor

Based on the interesting discussion in #149, it seems worth adding this side note:

image

@portsmouth
Copy link
Copy Markdown
Contributor Author

@anderslanglands and @KelSolaar Would appreciate your thoughts on whether this change makes sense.

@KelSolaar
Copy link
Copy Markdown

It might also be:

"... all RGB colours are in-gamut of the working space, i.e., have components in the $[0, +\inf]$ range"

  • "In-gamut" of what: We need to specify the container
  • Why limiting to 1]? Colour emission should not be restricted so we might need a case for albedo et al. and another one for emission.

@portsmouth
Copy link
Copy Markdown
Contributor Author

portsmouth commented Jun 4, 2024

@KelSolaar

It might also be: "... all RGB colours are in-gamut of the working space, i.e., have components in the $[0, \infty]$ range"

OK, so in your view "in-gamut" (of the working color space of the shader) simply means that the color components are non-negative?

"In-gamut" of what: We need to specify the container

Can you clarify what you mean by container? We say in the spec that "A color3 value is associated with a color space ACEScg by default" and that "The assumed color space of all the color parameters .. by default .. is assumed to be ACEScg".

So "in-gamut" is implied to mean in-gamut of that color space (or ACEScg if unspecified). Is that still under-specified in your view?

Why limiting to 1? Colour emission should not be restricted so we might need a case for albedo et al. and another one for emission.

Yes right, so emission color should not be restricted to [0,1], but it seemed like according to our earlier discussion we had agreed that for all the other colors, which represent albedos or fractional tints, they should be restricted to [0,1] (regardless of the color space). Do you still agree with that?

@KelSolaar
Copy link
Copy Markdown

OK, so in your view "in-gamut" (of the working color space of the shader) simply means that the color components are non-negative?

Yes, e.g., HDR values are considered in-gamut of their colourspace for example.

Is that still under-specified in your view?

I would certainly be very specific, there is an infinity of gamuts and it does not cost much to add.

Do you still agree with that?

Yes!

@portsmouth
Copy link
Copy Markdown
Contributor Author

Sorry can you clarify what you mean by “there is an infinity of gamuts”?

We say the color space must be specified (or is ACEScg by default). How can we be more specific that that?

@KelSolaar
Copy link
Copy Markdown

KelSolaar commented Jun 4, 2024

We are splitting hairs here but "gamut" by definition (Oxford Languages) is "the complete range or scope of something", what I'm saying is that the notes does not explicitly specifies it.

Note that we assume that all RGB colors are in the specified color space's gamut, i.e. have components in the $[0, +inf]$ range.

This is better because the "something" is specified explicitly in the sentence right next to "gamut" and you do not have to reach the end of the sentence to understand the full context.

In theory, the i.e., portion of the sentence could be omitted and the sentence would be explicit by itself, I could only write:

Note that we assume that all RGB colors are in the specified color space's gamut.

@portsmouth portsmouth changed the base branch from main to dev_1.1 June 7, 2024 16:35
@portsmouth portsmouth changed the base branch from dev_1.1 to main June 7, 2024 16:37
jstone-lucasfilm and others added 6 commits June 28, 2024 14:05
This changelist merges v1.1 development from dev_1.1 to main, in preparation for marking the release of OpenPBR v1.1.
Adding here the finalized logo. This is almost identical to the one posted on Slack, except:

  - extremely small adjustment to the arrow head, to make it perfectly centered on and orthogonal to the stroke

  - SVG was optimized to remove redundant elements (e.g. gradients). Main logo is now only 10Kb. PNGs exported at 800dpi.
@portsmouth portsmouth marked this pull request as draft September 17, 2024 18:38
@portsmouth
Copy link
Copy Markdown
Contributor Author

I modified this as follows:

image

image

image

@portsmouth portsmouth marked this pull request as ready for review September 30, 2024 20:24
@portsmouth portsmouth changed the base branch from main to dev_1.2 October 1, 2024 19:32
@portsmouth
Copy link
Copy Markdown
Contributor Author

@jstone-lucasfilm can be merged?

…oftwareFoundation#238)

Rather than eliminating the `specular_weight` > 1 case (as proposed in AcademySoftwareFoundation#228), we discussed keeping this but fixing up the metal logic to ensure the Fresnel remains bounded. This makes the corresponding change needed in the spec. (Note that now the `specular_weight` parameter consistently, for both metal and dielectric, has soft-range $[0,1]$ and full range $[0, \infty]$).

It would be good to double check that the behaviour of the metal looks reasonable for high `specular_weight` values (presumably, similar to the dielectric where the Fresnel saturates).
# Conflicts:
#	index.html
#	parametrization.md.html
…dation#218)

Some minor changes are needed to improve the clarity of the wording (around the implementation of the coat details). I discovered these while using the spec myself to implement the Arnold version.
@portsmouth
Copy link
Copy Markdown
Contributor Author

portsmouth commented Feb 21, 2025

Note we added:

The emission_color however is the exception which is permitted to have arbitrarily large (positive) components, since it represents an arbitrary luminance.

But the parametrization tables were not updated to make this change (despite the screenshots above?), so that is still to be done.

@AdrienHerubel AdrienHerubel self-requested a review May 27, 2025 17:56
@AdrienHerubel AdrienHerubel changed the base branch from dev_1.2 to dev_1.1.1 June 10, 2025 15:23
Copy link
Copy Markdown
Contributor

@AdrienHerubel AdrienHerubel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need a clean rebase on top of 1.1.1

@portsmouth portsmouth changed the base branch from dev_1.1.1 to main June 10, 2025 16:02
@portsmouth portsmouth changed the base branch from main to dev_1.1 June 10, 2025 16:02
@portsmouth portsmouth changed the base branch from dev_1.1 to dev_1.2 June 10, 2025 16:02
Adding here the finalized logo. This is almost identical to the one posted on Slack, except:

  - extremely small adjustment to the arrow head, to make it perfectly centered on and orthogonal to the stroke

  - SVG was optimized to remove redundant elements (e.g. gradients). Main logo is now only 10Kb. PNGs exported at 800dpi.
…oftwareFoundation#238)

Rather than eliminating the `specular_weight` > 1 case (as proposed in AcademySoftwareFoundation#228), we discussed keeping this but fixing up the metal logic to ensure the Fresnel remains bounded. This makes the corresponding change needed in the spec. (Note that now the `specular_weight` parameter consistently, for both metal and dielectric, has soft-range $[0,1]$ and full range $[0, \infty]$).

It would be good to double check that the behaviour of the metal looks reasonable for high `specular_weight` values (presumably, similar to the dielectric where the Fresnel saturates).
…dation#218)

Some minor changes are needed to improve the clarity of the wording (around the implementation of the coat details). I discovered these while using the spec myself to implement the Arnold version.
Implements the change described in AcademySoftwareFoundation#229.
# Conflicts:
#	index.html
#	parametrization.md.html
@portsmouth portsmouth changed the base branch from dev_1.2 to dev_1.1.1 June 10, 2025 16:16
portsmouth and others added 6 commits June 10, 2025 17:21
Adding here the finalized logo. This is almost identical to the one posted on Slack, except:

  - extremely small adjustment to the arrow head, to make it perfectly centered on and orthogonal to the stroke

  - SVG was optimized to remove redundant elements (e.g. gradients). Main logo is now only 10Kb. PNGs exported at 800dpi.
This changelist merges v1.1 development from dev_1.1 to main, in preparation for marking the release of OpenPBR v1.1.
Adding here the finalized logo. This is almost identical to the one posted on Slack, except:

  - extremely small adjustment to the arrow head, to make it perfectly centered on and orthogonal to the stroke

  - SVG was optimized to remove redundant elements (e.g. gradients). Main logo is now only 10Kb. PNGs exported at 800dpi.
@portsmouth
Copy link
Copy Markdown
Contributor Author

Can be closed, redone in #260.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants