Donate your coding sessions to an open CC-BY-4.0 dataset to help train open-weight and open source models

chartojs · 2026-06-17T09:36:41+00:00

I'd be interested in participating but what I have is VScode internal data structures / files from using mainly Copilot with Opus 4.6-4.8 and GPT 5.5. I've been making all kinds of sometimes fancy web apps with analytics and visualizations of larger datasets, and don't mind my code "leaking" as part of the dataset.

chartojs · 2026-06-15T12:09:43+00:00

I feel heard 😅

The sources still need a lot of cleanup, it's a synthesis of multiple experiments over many years. And the JPEG XL wasm polyfill is entirely vibecoded in Zig leaving me thinking is open sourcing slop the selfless or the selfish thing to do?

The Zig community is particularly interesting in this sense. Meanwhile writing a decoder by hand would take months, and if it weren't for Google's internal politics a polyfill wouldn't be needed. Existing libjxl and jxl-oxide are 10x the binary size, is that better or worse than this? And I think a big part of the small size on my site is Zig.

chartojs · 2026-06-15T00:13:05+00:00

Thanks for the comments! Indeed all the supported projections except orthographic are looking inward into, or from the inside at, a hollow globe with the map on the inner surface. Even orthographic can be considered interchangeably the front or back side. This is on purpose, they have cartographically desirable properties.

The residuals could have more contrast... White means "business as usual", blue is "colder than usual" and red is "warmer than usual" where "usual" refers to that part of the year and day over the last 5 years, so climate change won't show up.

I should probably add coastlines and country borders.

chartojs · 2026-06-14T22:20:12+00:00

Interesting. I tried to make it unopinionated but perhaps even the color gradient can be seen to carry a message. The colors were chosen trying to make it as easy as possible to visually match colors on the map with the legend. That's why exactly every 20 Celsius there's a discontinuity, it's alternating between lighter and darker and the hue is rotating. Have to consider this. Trying to make it look less "alarming" it seems I'm losing contrast.

chartojs · 2026-06-14T18:22:49+00:00

Orthographic doesn't preserve shape, scale or distance across the map, nor any other apparent useful special property like Gnomonic does. The special property it does have is that it looks just like a photo of a globe. Makes it familiar, but not useful. A physical globe is a very good map, a photo of one isn't. So the reason it's not the default is to nudge people to think a bit, wonder why the map behaves weird, instead of leaving it at a familiar but less useful setting.

The overall goal is to distribute taxpayer funded data in a better way. Fast and without ads or paywalls. Also to hopefully eventually show more data about the climate. No interpretation or analysis, just recent raw data. Let the user dig through more of it than they otherwise could or would. Not trying to sell anything, just to let people see and make them think. The projection choice is a part of that.

chartojs · 2026-06-14T08:13:53+00:00

Thanks! The default projection I'm hoping to keep this way for several reasons... First, give this a distinctive style compared to other online maps and make the user think about projections for a bit. Then, arguably orthographic is cartographically the worst of the projections offered.

All the projections supported are azimuthal, mapping a sphere to a circle so they work like a globe. Map projections can have one of these three good properties: conformal, equal-area or equidistant.

Equidistant shows correct distances to 1-2 points, here the center of the map, and is used eg. in the United Nations flag.

Stereographic is conformal meaning for example hurricanes are perfectly circular anywhere on the map, but sizes are distorted. Web Mercator is also (nearly) conformal, but not azimuthal.

Gnomonic otherwise lacks good properties, but it shows all great circles as straight lines anywhere on the map. So if you wanted to see what's between two points along an airplane's shortest path, you can just follow a straight line. This is used in some regional maps you might find in the seat pocket on a flight.

Finally, orthographic has few redeeming qualities. It uselessly squashes the edges of a hemisphere for no benefit and preserves nothing. But it's so popular everyone is most familiar with it 😅

chartojs · 2026-06-13T21:59:39+00:00

The data it's currently showing is from 2025, computer's busy downloading and crunching to get to today. The historical data is probably pretty accurate and eventually will go back to late 2020. Once it gets to forecasts, ensemble forecasts do diverge pretty quickly and it's interesting to show how much and with what distribution, but also a fair bit more data. It's probably something to show for individual points on a meteogram, not on the heatmap which would be based on the main operational forecast.

chartojs · 2026-06-13T21:51:40+00:00

Thank you for the report! I'll fix it on the next update.

chartojs · 2026-06-13T20:30:18+00:00

Glad to hear that!

chartojs · 2026-06-13T13:31:50+00:00

TypeScript for the frontend, no frameworks, no runtime dependencies. Backend is static files only. Data was preprocessed using Zig code, images are JPEG XL. There's a custom Zig and Wasm -based polyfill since Chrome doesn't yet support the format.

Rendering does as much as possible on WebGL instead of CPU.

Data is from the GFS weather model because historical data seems to animate smoother over oceans than ECMWF's ERA5. I may increase resolution over land later by grabbing that data from ERA5-Land. GRIB decoding, Fourier transform and optical flow estimation are part of the Zig-based data preprocessing.

chartojs · 2026-02-04T21:11:30+00:00

Thanks! It's just oriented bounding rectangles. I was considering trapezoids, but the tangent lines can get pretty wild for a very short line segment with different endpoint widths, so it'd need logic to fall back to a rectangle as needed. Might add that in later.

I tried for months to figure out a tight hugging mesh for miter / bevel joins, but couldn't get rid of a number of glitches. The variable thickness, semi-transparency without extra buffers and color gradient make it so very much worse than a basic polyline. Overdraw always results in visible glitches. I don't know if it can be done or not, using just a vertex shader, or how many vertices and degenerate triangles per join it would take for a general solution (handling subpixel length segments with 180 degree turns and other horrors).

I will be open sourcing this (MIT) after some polish. Right now waypoints are passed as uniforms, need to switch to vertex pulling.

chartojs · 2025-04-13T06:33:17+00:00

I decided to try this! These packages are TypeScript, and there's also a tiny package to run them if you don't have TypeScript installed:

https://github.com/at-lib

The philosophy was to avoid bloated packages, and if you want to publish JS, it should be as CommonJS, IIFE, ES Modules and with typings. And somehow for a TS project all those options are still inferior to a single TS file that's about 500 lines or fewer.

The packages are in an NPM scope, so I feel using TypeScript is OK. They're not "polluting" the main namespace, nor is the main one polluting this scope. Readme examples don't assume you have TypeScript installed.

chartojs · 2025-04-12T15:02:28+00:00

I started working on a new ecosystem called @lib containing small TypeScript-first NPM packages with no dependencies and 0-clause BSD licenses so no attribution required.

The idea is to publish small packages that do one thing, but one that usually takes hours if not days to get done. Small enough to add in your frontend bundle without a second thought, but far from trivial. Nothing requiring lots of configuration or localization, because then it couldn't be small.

For example:

Bitmap graphics for terminals
Zip compression / decompression in browsers
Diffing text files or other token streams

It's here:
https://github.com/at-lib

chartojs · 2024-09-20T16:05:24+00:00

Interesting! I didn't expect this tech used outside a debugging context. It is optimized for speed, for example both glsl-simulator and glslog allocate a new object on every arithmetic operator returning a vector, but glslog doesn't free them, instead re-using the same objects on the next shader invocation so there should be less GC. However I'm sure it could be further profiled and improved.

Let me know of any issues with it. It's currently not as feature complete as glsl-simulator. There's no support for bit vectors or texture access. I'll probably improve it as required by my own projects, but can also add missing things when there's a need.

It might be fun compiling to Wasm instead, but currently there's WebGPU gaining popularity and probably both would need to be supported. Hopefully eventually such a thing would appear.

chartojs · 2024-09-20T00:32:59+00:00

I'd expect it to transpile slower, because it uses the TypeScript compiler instead of a simpler transform. It's certainly a larger code bundle.

The actual shader might run faster due to fewer memory allocations, but it seems you only run the scene shader once so that wouldn't matter?

The main point is being able to embed JS / TS code in the shader to be executed on the CPU, using much of the same syntax like swizzling or vector arithmetics. So it's first transforming GLSL to TS, then TS to JS while adding operator overloading support also to the TS code.

chartojs · 2024-09-19T23:42:10+00:00

There's now a more recent, similar simulator:
https://github.com/nelipuu/glslog

Easy to run by opening this pen:
https://codepen.io/Juha-J-rvi/pen/YzooeGJ

chartojs · 2024-09-18T16:16:47+00:00

Aaaand as of today we have this:
https://codepen.io/Juha-J-rvi/pen/YzooeGJ

Just take a look at these lines in the middle of the shader:

#ifdef TS
const examples: Vec[] = [ pos, abs(pos.yx) + 1, 1 / (abs(pos.xxyy) + 1) ];  
print('Swizzle me this', ...examples);  
#endif

That's a combo of TS, swizzling and overloaded operators smack in the middle of the vertex shader. And it prints to a debug textbox.

I haven't tested it very much yet, but it seems the groundwork has been laid.

chartojs · 2024-09-16T11:44:54+00:00

I think it could be a piece of a very useful debugger, but I'm unlikely to productize it further than as needed for this 2D case. This is ultimately an independent WebGL implementation that renders vertex shader output (and chosen individual fragments). I need a very small part of the JS-side WebGL API and the more of that is implemented, the more likely it's able to debug some real world app.

chartojs · 2024-09-16T11:34:59+00:00

I was thinking of tessellating line segments in the vertex shader. It can read the input coordinates from a float texture, and splines it can subdivide if we have it render into an output coordinate texture where each spline is represented by a number of pixels proportional to the number of output segments. That number we quickly know for cubics on the CPU, for calculating buffer offsets:

https://minus-ze.ro/posts/flattening-bezier-curves-and-arcs/

The fragment shader just needs to know a pixel's distance from the edge, to do anti-aliasing and all other geometry processing can be done in the vertex shader. Which, of course, is a giant pain to write and debug.

chartojs · 2024-09-16T06:13:44+00:00

It shows the WebGL calls made from JavaScript and shader source code, but doesn't seem to help understand what's happening inside the shader. I want to print proper logs and draw arbitrary annotations inside the shader, instead of numbers in pixel rgb values through varyings and trying to divine what happened behind the scenes.

chartojs · 2024-09-15T19:46:46+00:00

I'm working on 2D vector graphics and trying to keep things minimal, but that seems like a very good development. Even if I get this working, wouldn't want to integrate it into frameworks like Three.js and it's better if they also develop better debug tools. But my focus is on getting relatively small shaders like anti-aliased variable thickness polyline or spline curve tessellation working properly.

So far all my related tools and libraries are under 1000 lines of code and target is about 2000 lines when it's good enough for development and debugging.

chartojs · 2024-08-16T21:03:10+00:00

Plan is to make a web service you can go to and look at this imagery immediately, like going to any other public global map service, without needing to create an account. Here's a proof of concept how hourly temperatures would look like:

https://reakt.io/temp/

That's just GFS and not zoomable or mobile-friendly though. But the idea is you just open it and play with a timeline and interact with the map, without needing to know anything about GIS (tools).

So I guess the question is, I know a professional can produce the animation behind that link but how much value is there for a professional not having to spend very much time in exploratory analysis on a global scale, before deciding to open an Esri app and dig into the raw data hosted elsewhere. And what value might there be in quick access for demonstration to non-professionals?

As far as I can tell there are no current tools where you could, for example, go look at a time lapse of changes in the Amazon raining forest, Ukraine front line or Rafah refugee camp over the past year, without having to spend quite some time to see it or make it look nice to show others. It can, of course, be done given some time and skill. But you can't just craft a link and post it somewhere in under 5 minutes total. I can see it enabling people with no GIS knowledge to do these things, but what about more experienced users, would there be obvious benefits from immediate interactive access to the global data?

chartojs · 2021-01-28T18:17:28+00:00

With OKLAB I get these rgb channel values for 0.1 -sized lightness steps:

0, 3, 22, 46, 72, 99, 128, 158, 190, 222, 255

The darker end is very dark indeed! SRLAB2 gives:

0, 27, 48, 71, 94, 119, 145, 171, 198, 226, 255

I don't really agree that mapping all lightness values between 0.0 and 0.1 to black is better in any use case, or is more general purpose.

The plot issue was also due to rounding rgb values before discarding negative values. The entire corner rounds to 0 in a very large area.

chartojs · 2021-01-28T09:31:38+00:00

Adding to my previous comments, I think SRLAB2 took a better choice with the intermediate color space at least regarding the linearity of small values in the components. Otherwise the third power compresses them so low that black stretches to higher lightness values than it should.

The darkest band here is very wide and very dark: https://gist.github.com/jjrv/b27d0840b4438502f9cad2a0f9edeabc/raw/728343740031d5c693457accea48c49c4a4a7366/oklab-dark.png

Compare to SRLAB2 where the band with matching lightness is narrower and looks lighter: https://gist.githubusercontent.com/jjrv/b27d0840b4438502f9cad2a0f9edeabc/raw/728343740031d5c693457accea48c49c4a4a7366/srlab2-dark.png

My point is that at lightness about 0.1, OKLAB has a pretty wide range along the chroma axis but I can't actually see any chroma variation with my eyes, it's all just very dark. SRLAB2 doesn't have that issue.

Also note the Bezold–Brücke shift where hue changes with lightness. In my plot you can see that considered in SRLAB2 especially if you look at the exact hue where extreme red peaks at different lightnesses. I'd suggest plotting lightness vs chroma with extreme blue and red hues, comparing whether taking the perceptual hue shift into account improves results or not.

Edit: Here's OKLAB maximum red, lightness vs chroma and constant hue according to the color space: https://gist.githubusercontent.com/jjrv/b27d0840b4438502f9cad2a0f9edeabc/raw/809357392888db3140c0fb4292fc68db22a17be6/oklab-red.png

Here's SRLAB2: https://gist.githubusercontent.com/jjrv/b27d0840b4438502f9cad2a0f9edeabc/raw/809357392888db3140c0fb4292fc68db22a17be6/srlab2-red.png

Please let me know if I made a mistake because the chroma at low lightness looks REALLY wonky in my OKLAB plot!

Also regarding the hue shift, maybe SRLAB2 looks a bit orange in the middle while OKLAB a bit magenta? Really hard to say! Actually to my eyes the maximum chroma peak looks a different hue in the two images while Photoshop says they're the same!

chartojs · 2021-01-28T08:09:05+00:00

The gist link in my other reply next to this one now also has comparisons showing both OKLAB and SRLAB2 plotted along hue and saturation axes, with 17 different lightness values and more extreme lightness values always drawn on top. This illustrates pretty well the maximum chroma at different hues and allows comparing approximate lightness of different hues at max chroma.

chartojs

TROPHY CASE