jeremyscanvic

Really cool! Any specific reason for the choice of Oklab instead of say HSL/HSV?

Any reference you can share on this? I'm genuinely curious speaking as a PhD student in image processing for computer vision

Something that's important to bear in mind when displaying raw images like that is it's not so much that raw images need to be processed to look good intrinsically. It's much more that they need to be processed to be in the form displays expect. Gamma correction is only needed because displays expect gamma corrected images and they automatically try to undo the correction.

Do you have any evidence to back this up? I'm asking out of genuine curiosity

I read Sad Tiger by Neige Sinno. Really unsettling but definitely worth reading.

I would assume you pretty much get that out of the box given Typst compiles to HTML natively?

Seems to be what those guys are up to: https://typst.app/universe/package/mitex/

I've encountered this several times and even though I found it frustrating it didn't occur to me it could be something that could/should be fixed. You're always going to have some quirks if you want a syntax without too much parentheses right?

I've been really pleased with Typst so far - fast rendering, less verbose than (La)TeX in many ways (backslashes hurt now!) and unicode/emoji support really seals the deal. (Disclaimer: only using for semi-formal slides and notes, not for papers and important presentations)

Pivot tables rock! I wouldn't be surprised if they were studied mathematically and proven to be somewhat capable of everything you might want to do in the context of tabular data processing.

Thanks for correcting me - I see my web sec knowledge is getting rusty!

Erratum: What I'm saying here only applies for cookies with the attribute SameSite=None so it's irrelevant here, see the comments below.

(Former CTF hobbyist here) You might be mixing up XSS and CSRF protections. Cookie protections are useful against XSS vulnerabilities because they make it harder for attackers to get a hold on user sessions (often mediated through cookies). It doesn't really help against CSRF attacks though. Say you visit attacker.com and it contains an auto-submitting form making a POST request to yourwebsite.com/delete-my-account. In that case, your cookies would be sent along and if no CSRF protection is there (origin checks, tokens, ...) your account might end up deleted. I know it doesn't answer the original question but hope it's useful information nonetheless!

The part about AI being very sensitive to small perturbations of their input is actually a very active research topic (and coincidentally the subject of my PhD). Most vision AIs suffer from poor spatial robustness [1], you can drastically lower their accuracy simply by translating the inputs by well-chosen (adversarial) translations of a few pixels! I don't know much about text processing AIs but I can imagine their semantic robustness is also studied.

[1] https://arxiv.org/abs/1712.02779

Edit: typo

Really excited about this - we've recently been struggling with making imports lazy without completely messing up the code in DeepInverse https://deepinv.github.io/deepinv/

I keep hearing this exact same idea and it puzzles me a great deal. Is it a computer science thing? I'm doing a PhD in signal processing / engineering and people seem to care a lot about giving simple and clear explanations so I don't really relate!

The keyword you're looking for is time-frequency analysis and the main associated tool is the short-time Fourier transform(s). This is the theory underlying spectrograms and all those niceties!

Exactly what I was looking for while reading the post. Thanks!

Neat! This is known as a stabilizer in the digital art community.

I think we have different things in mind here - I believe you're thinking of upper vs lower layers of code and I'm thinking of the code being literally at the top or bottom of a script or function. Thanks for sharing your thoughts anyway!

Writing code from bottom to top instead of from top to bottom. Usually the interesting stuff happens in the bottom part and the top part is merely prepping data and taking care of edge cases: it's way easier to write it once you know how you're gonna end up using it.

Really interesting write-up! I'm not very familiar with signed distance functions but aliasing is a major part of my PhD and this is really insightful to me!

You might be interested in Lean's way of doing things. They have normal types (e.g. numeric types) and subtypes (e.g. numbers less than zero). An element of the subtype "numbers less than zero" can be understood as a tuple containing the actual number (which has a normal numeric type) and a proof that this specific number is indeed less than zero.

https://lean-lang.org/doc/reference/latest/Basic-Types/Subty...

That's really neat. I didn't know about those string constants!

That's really neat! I'm very excited for the future of Lean.

Really interesting trick!

The fixed rendering looks really nice. Good job!

I might be missing something but you sound genuinely confused to me. The perspective in your post is linear perspective. It's the one used in CSS and it doesn't curve straight lines/planes. It's not the perspective of fish-eye images (curvilinear perspective).

I think GP's point is that besides the unavoidable distortions coming from approximating a perspective transform by a piece-wise affine transform, the implementation remains incorrect.

Also known as the good ol' straight lines remain straight in perspective drawing!

This is so exciting! My colleagues are doing research in astronomical imaging except on the more theoretical side of things - it's really neat to come across cool downstream applications like that!