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

Comments for Basic 2D Rasterization #28

Open
magcius opened this Issue May 29, 2017 · 9 comments

Comments

Projects
None yet
5 participants
@magcius
Owner

magcius commented May 29, 2017

@yarwelp

This comment has been minimized.

Show comment
Hide comment
@yarwelp

yarwelp May 30, 2017

Very interesting article. Well written and it answers several questions that I've had but which I hadn't previously gotten around to investigate. Looking forward to the next article in the series.

yarwelp commented May 30, 2017

Very interesting article. Well written and it answers several questions that I've had but which I hadn't previously gotten around to investigate. Looking forward to the next article in the series.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 30, 2017

Great article. If you weren't going to already, I'd suggest covering sRGB, as it's fundamental for correct interpolation of color gradients (and AFAIK for correct alpha blending as well).

ghost commented May 30, 2017

Great article. If you weren't going to already, I'd suggest covering sRGB, as it's fundamental for correct interpolation of color gradients (and AFAIK for correct alpha blending as well).

@magcius

This comment has been minimized.

Show comment
Hide comment
@magcius

magcius May 30, 2017

Owner

I'd suggest covering sRGB, as it's fundamental for correct interpolation of color gradients (and AFAIK for correct alpha blending as well).

The biggest issue is that since this is the web, I'm constrained to web APIs, and the web APIs managing color are... uh... poor, to say the least.

The official HTML5 spec says this on canvas color spaces:
https://html.spec.whatwg.org/multipage/scripting.html#colour-spaces-and-colour-correction

But according to this thread on whatwg, this is an inaccurate summary of what browsers do:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0164.html

Wide gamut support is coming soon:
https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md
https://bugs.chromium.org/p/chromium/issues/detail?id=634542

I'll have to do my own tests, but it's probably correct that when using putImageData, the values are not linear, so a linear interpolation gets us junk. But I don't know if it's sRGB or the output profile space, and if it's the latter, I don't know if I can pull the color space out to properly blend.

Thanks for the recommendation, though! It's definitely a huge thing I gloss over in the article itself, making the simplification that color is linear. That is totally wrong and should correct it in a follow-up. :)

Owner

magcius commented May 30, 2017

I'd suggest covering sRGB, as it's fundamental for correct interpolation of color gradients (and AFAIK for correct alpha blending as well).

The biggest issue is that since this is the web, I'm constrained to web APIs, and the web APIs managing color are... uh... poor, to say the least.

The official HTML5 spec says this on canvas color spaces:
https://html.spec.whatwg.org/multipage/scripting.html#colour-spaces-and-colour-correction

But according to this thread on whatwg, this is an inaccurate summary of what browsers do:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0164.html

Wide gamut support is coming soon:
https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md
https://bugs.chromium.org/p/chromium/issues/detail?id=634542

I'll have to do my own tests, but it's probably correct that when using putImageData, the values are not linear, so a linear interpolation gets us junk. But I don't know if it's sRGB or the output profile space, and if it's the latter, I don't know if I can pull the color space out to properly blend.

Thanks for the recommendation, though! It's definitely a huge thing I gloss over in the article itself, making the simplification that color is linear. That is totally wrong and should correct it in a follow-up. :)

@smurfix

This comment has been minimized.

Show comment
Hide comment
@smurfix

smurfix Jun 13, 2017

You wrote that you're using t*t*(3 - t*2) as a smoothstep function. That doesn't make sense, as the first derivative at t=1 is not zero. You want t*t*(3 - 2t).

smurfix commented Jun 13, 2017

You wrote that you're using t*t*(3 - t*2) as a smoothstep function. That doesn't make sense, as the first derivative at t=1 is not zero. You want t*t*(3 - 2t).

@magcius

This comment has been minimized.

Show comment
Hide comment
@magcius

magcius Jun 13, 2017

Owner

I'm not sure I understand. How is t*2 different from 2t?

Owner

magcius commented Jun 13, 2017

I'm not sure I understand. How is t*2 different from 2t?

@smurfix

This comment has been minimized.

Show comment
Hide comment
@smurfix

smurfix Jun 13, 2017

sorry, my brain fart.

smurfix commented Jun 13, 2017

sorry, my brain fart.

@metroidchild

This comment has been minimized.

Show comment
Hide comment
@metroidchild

metroidchild Aug 2, 2017

I'd enjoy all sorts of random fun in other interactive demos, whether it be compression algorithms or anything else, I like the format

metroidchild commented Aug 2, 2017

I'd enjoy all sorts of random fun in other interactive demos, whether it be compression algorithms or anything else, I like the format

@valsoray17

This comment has been minimized.

Show comment
Hide comment
@valsoray17

valsoray17 Jan 31, 2018

Amazing article! Very informative and fascinating! Thank you.

One question: shouldn't it be coverage /= nSubpixelsX * nSubpixelsY;? in the

// Take the average of all subpixels.
coverage /= nSubpixelsY * nSubpixelsY;

It's irrelevant for a square grid, but can it be non-square?

valsoray17 commented Jan 31, 2018

Amazing article! Very informative and fascinating! Thank you.

One question: shouldn't it be coverage /= nSubpixelsX * nSubpixelsY;? in the

// Take the average of all subpixels.
coverage /= nSubpixelsY * nSubpixelsY;

It's irrelevant for a square grid, but can it be non-square?

@magcius

This comment has been minimized.

Show comment
Hide comment
@magcius

magcius Jan 31, 2018

Owner

Good eye! Yep, that's a typo. Fixed in 770ac99. In the actual demo code, it's correct: https://github.com/magcius/xplain/blob/gh-pages/src/article-demos/rast1.js#L242

Owner

magcius commented Jan 31, 2018

Good eye! Yep, that's a typo. Fixed in 770ac99. In the actual demo code, it's correct: https://github.com/magcius/xplain/blob/gh-pages/src/article-demos/rast1.js#L242

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