[css-color-4] Correction to ray trace to avoid throwing off our intersect calculation and match MINDE flow #10579 #13416
Conversation
…section calculation The suggested fix via w3c#10579 (comment) was not the ideal fix and artificially limited `tnear`. This is a numerical instability issue and should be addressed as such by using an epsilon compare to prevent rays that are too small. Related w3c#10579
facelessuser
force-pushed
the
css-color-4/fix-raytrace
branch
from
d55fb79 to
db955e1
Compare
|
@facelessuser could you please:
I can then make a link for an individual royalty free license commitment (for the whole Ray Trace GM, not just this specific pull request). Thanks! |
|
Excellent, I'll create an account! |
- Return unbounded colors - Return black/white if SDR lightness is exceeded. - Then if color is out of gamut continue chroma reduction
facelessuser
changed the title
|
Cool, I've made the request and also updated the algorithm to better match the CSS MINDE flow. This also addresses the concern about clipping and converting to the destination space. I've updated it to follow what CSS MINDE does. A final note, I settled on 1E-12 for the ray size threshold. It's generally recommended either 1E-9 or 1E-12 for high precision cases in double floating point. I'm probably indifferent to whichever, as I don't think there would be a significant difference. |
|
I've made the account and linked GitHub. |
|
Thanks! The request for non-participant license commitment has been sent. |
2 participants
My suggested fix via #10579 (comment) was not the ideal fix and artificially limited
tnear. This is a numerical instability issue and should be addressed as such by using an epsilon comparison to prevent rays that are too small. This corrects the fix.I've also adjusted the algorithm to match the flow of MINDE in regardless to checking lightness before returning out of gamut colors.
I also revised the cleanup step. Since the destination is a gamut-bound space, we can clip there as we do in MINDE.
Related #10579