The problem is "for each pixel inside the area". I could have done that, and then clipped the output by that shape. The problem is this doesn't answer why the shape is this way at all because you are using the shape itself to clip the output. It felt fake.
Ok, so you're asking why every visible color has to lie within the bounds of the spectral locus in the chromaticity diagram?
The reasoning is simple:
1. Spectral colors are basis vectors of the color spectrum. I.e. every possible spectrum can be thought of as a weighted sum of infinitely many Dirac deltas. With nonnegative weights, in particular, so it's a so-called conical combination (i.e. linear combination with nonnegative weights).
2. Taking the inner product with color matching functions is a linear transformation from this infinite dimensional space spanned by spectral colors to a 3-dimensional space. Linearity means that weighted sums are preserved, that is: every possible color spectrum's XYZ values are going to be the weighted sum of the spectral colors' XYZ values. And because the XYZ color matching functions are nonnegative everywhere, conical combinations are also preserved.
3. And finally, the conversion from XYZ to xyz is such, that it turns conical combinations into convex combinations (i.e. conical combinations where the weights sum to 1). It's easy to verify this with pen and paper.
It follows, that every color on the xy chart is going to be a convex combination of xy points corresponding to spectral colors, which geometrically means that they're going to lie inside the spectral colors' convex hull.
Yeah that article is better. I'm the author and I wrote this only for me as I studied it, it's not great as a way to describe it to others
I wanted to start from the very beginning and as far as I know Lab and OKLab didn't come later. Studying the 1931 studies and such was a start, and I wanted to later bring up all the other things we've learned since then, but haven't had time to write more about it
I appreciate this color to your article. My background (3rd/4th career) was developing tests and compensation algorithms for visible defects in consumer displays. It was a real learning experience and trying to understand the many ways that people try to control the display of and quantify image color was daunting. Also amazing, both what trained people CAN see, and what most people CAN'T.
And techniques for helping people see. I am working to get a shade of yellow right that tends to turn orange in my toolchain. The best method I've developed is to compare several prints and colors on the screen to the actual object.
It's hard to tell how exact a particular shade of yellow is, but if you have several shades the correct one stands out immediately.
but you're right, the intensity needed of each R, G, and B light sources to produce the correct color is directly related to how our eyes perceive each of those sources, so yes you are correct
Hey! I'm James, the original creator. Yeah, I tried to stay involved but over time I had to accept that my life right now just doesn't allow time to be very involved. We've had some incredible maintainers step up and their doing an amazing job stewarding the project along.
I'm long-overdue to check in with the maintainers and write some content about the transition. I was also intending to shutdown the hosted version late summer and hand over actualbdget.com to the open-source community. My goal is to do this by end of year.
Overall, I wish my life weren't so busy in some ways, but it's busy with really good and fulfilling things. The transition was a little rough for me (hard to give control away of something I worked so hard on) but it's turned out surprisingly good
Native apps were open-sourced yes in the repo, but the community moved them out into their own repos and archived them. Hard to build native apps open-source with all the tooling, and the community has been working on replacing them with a webapp
What's shutting down is the public syncing server. That server is literally just a message store: it takes CRDT changes and puts them in a big table. And it servers them back out.
Now that the server is public, it's incredibly easy for you to run your own. It's such a simple server (no postgres etc requirement) that this model is actually way better.
CRDT's and the like seem like the perfect thing to build an app, but you make a good point about it requiring something so custom compared to a thin client that makes web service requests for data on each screen / page view.
> you make a good point about it requiring something so custom
The comment you're replying to didn't say this at all, the developer did. In theory it's also wrong. The server can be application agnostic. It shouldn't care whether the CRDT update is from a budget app or an RSS reader or whatever else, because the sync job for the server is exactly the same. You should also be able to encrypt the content, and therefore set up generic shared CRDT servers instead of requiring people to run their own.
It only requires more work now because nobody has built that yet.
I launched around 3 years ago, and it was brutally slow. I think it took a year to hit 100 subscribers.
Another year to hit 300.
This past fall, YNAB increased their prices which gave me decent jump from around 500 to 800 subscribers which is where I'm at today.
I did everything wrong when it comes to marketing and getting subscribers. I focused on the tech and never invested in content, building hype, etc. Well, I take that back -- sometimes I did, but only 10% instead of 70% like I should have been doing.
As a bootstrapped solo founder myself (even though I have somehow built a small team after 7 years), I totally get what you are saying. Be proud of what you did and most don't even get to do what you did. It is so hard to do things alone and especially when you realize it is mostly about Marketing and Sales (and not the product only).
I'm a firm believer that the only way to stand out in the B2C world is to have a VC backed marketing budget. You can't bootstrap a positive CAC in a reasonable timeframe without going bankrupt as a solo founder.
Yes I totally regret it. There are ethical VCs that would be willing to invest a small amount and I should have done that. Bootstrapping isn't all it's cracked up to be; there are a lot better and smarter ways to kickstart a project.
but if you can't generate enough revenues to justify valuations you wouldn't go anywhere either. i guess it is better to find that out after raising millions and paying yourself a fat salary
It's in an established and competitive market. There's money flowing into companies doing this same thing. An investor throwing (some) capital at marketing and growth for this totally functional (and beautiful) product could have made sense.
If the community want to wait, I'm happy to push back the date.
I actually thought it felt less greedy to not wait too long, because doing it in the far future just means people are paying for unsupported software. Happy to keep it running though for as long as people want.
I'm not using your software, but as somebody who has had to switch personal finance apps multiple times, I'd personally want to be able to use it through the end of the year. It's easier to just start a new program at a new year.
The problem is "for each pixel inside the area". I could have done that, and then clipped the output by that shape. The problem is this doesn't answer why the shape is this way at all because you are using the shape itself to clip the output. It felt fake.
I do think this is what is most common though. I was trying to understand a more rigorous approach, and the one where you generate spectra and try to fill it is described here: https://clarkvision.com/articles/color-cie-chromaticity-and-...
That feels like a more rigorous approach, but clipping is probably "good enough" too