Instead of training on vast amounts of arbitrary data that may lead to hallucinations, wouldn't it be better to train on high-resolution images of the specific subject we want to upscale? For example, using high-resolution modern photos of a building to enhance an old photo of the same building, or using a family album of a person to upscale an old image of that person. Does such an approach exist?

Author here -- Generally in single image super-resolution, we want to learn a prior over natural high-resolution images, and for that a large and diverse training set is beneficial. Your suggestion sounds interesting, though it's more reminiscent of multi image super-resolution, where additional images contribute additional information, that has to be registered appropriately.

That said, our approach is actually trained on a (by modern standards) rather small dataset, consisting only of 800 images. :)

It feels like it's multishot nl-means, then immedeately those pre-trained "AI upscale" things like Topaz with nothing in between. Like, if I have 500 shots from a single session and I would like to pile the data together to remove noise and increase detail, preferably starting from the raw data, then - nothing? Only guys doing something like that are astrophotographers, but their tools are .. specific.

But for "normal" photography, it is either pre-trained ML, pulling external data in, or something "dumb" like anisotrophic blurring.

I'm not a data scientist, but I assume that having more information about the subject would yield better results. In particular, upscaling faces doesn't produce convincing outcomes; the results tend to look eerie and uncanny.

Not a data scientist, but my understanding is that restricting the set of training data for the initial training run often results in poorer inference due to a smaller data set. If you’re training early layers of a model, you’re often recognizing rather abstract features, such as boundaries between different colors.

That said, there is a benefit to fine-tuning a model on a reduced data set after the initial training. The initial training with the larger dataset means that it doesn’t get entirely lost in the smaller dataset.

That is how Hollywood currently de-ages famous actors, by training on their photos and stills from when they were around the desired age.

But it's extremely time-consuming and currently expensive.

That is effectively what it's doing already. If you examine the artifacts, there is obviously a bias towards certain types of features.

pretty sure a memory access is faster than the methods presented in the article.

Depends also heavily on the context. You pay for each cache miss twice - once for the miss itself, and next time when you access whatever was evicted during the first miss. This is why LUTs often shine in microbenchmarks, but drag down performance in real world scenarios when mixed with other cache bound code.

Hitting L2 is more than 3-4 cycles

Access to main memory can be many many cycles; a short routine already in cache may be able to recompute a value more quickly than pulling it from main memory.

An uncached random memory access is around 100 cycles.

100 cycles would be very low. Many systems have more than 100 ns!

You are correct. I used the wrong unit:

https://jsmemtest.chipsandcheese.com/latencydata

We can say around 100ns, although likely somewhat more.

64K is enough to fill L1 on many systems

There is room for only one blockchain app in the world we live in. And that is for Bitcoin.

I've been there, and it was a pain. All my backups were corrupted due to a faulty RAM module. Initially, I blamed the hard drives because they seemed to be failing right before my eyes. I was copying a large file; sometimes it copied okay, but occasionally it would become corrupted. Since then, I've been paying a premium for ECC.

Same experience. We were doing all the things, regular backups, rotating them, verifying them. During a weekly verification test, it failed. Tested some older backups and they failed too! If the data matters, it’s hard to express the stress and disconcert you feel in this moment.

Memory is different from all other resources in the system. We are conditioned as engineers, we know drives fail more frequently than other resources. When memory fails it is indistinguishable from a drive failure. There are some system behaviors that matter too, we tend to think that page allocation is random and on heavily loaded systems it appears to be, but on specialized systems it can be rather consistent so the verification can fail in nearly the same place, repeatedly. Riddle me this: what is more likely? A memory failure, a drive failure, or a postgresql bug that results in a corrupted row? Badblocks checks out on the server’s disks… if the data matters, it is extremely unpleasant going through that whole thing, it’s crystal clear after the fact but it’s a bloody nightmare in the heat of it all.

so, it's full screen compiled sprites.

Yes, combined with streaming the data from disk in realtime, and playing the audio over the PC speaker in this case, bit-banged. Given the limited performance of both the HDD system and the CGA adapter, the most important thing the compiler has to do is to stay within the budget of HDD and CGA resources.

The demoscene has always been about real-time graphics. It never sought to compete with video animations. Many demosceners were, at heart, game developers who valued and appreciated real-time code, often considering animations to be "lame".

But that's the point. Today this is a big distinction that makes it more difficult for many people to appreciate.

When we saw Commodore 64 demos for example, they often impressed even relatively non-technical people.

But today a demo that pushes the limits technically will often only look impressive to those who understand the technical limitations.

That has significantly changed the potential audience to a diminishing subset even if relatively technical people.

Anyone who plays AAA games knows the currently state of the art and technical limitations. Sure it's not everyone, but a large enough non-technical portion of the population will be able to appreciate it, to some degree.

This is assuming that they'll look at a non-interactive demo and get why someone would insist on not pre-rendering everything in the first place instead of comparing it against pre-generated video. That was becoming a problem already 20+ years ago in explaining to people what made a given demo impressive, because most people aren't interested in the technical limitations.

I totally agree that this was the opinion of many demosceners. However, my point is that this would seldom be the opinion of the general public. The demoscene grew organically, and trying to define what it should be about seemed a bit silly. The artificial limits, such as 64K or 4K intros sure were fun to compete with, but they make little or no sense to the uninitiated, and were pretty much arbitrary.

It was actually what put me off a bit -- I enjoyed the demoscene to learn new things and to experiment with computers in total freedom. I had no need for artificial limitations set out by competitions, and never really cared much for the gatherings of socially less developed boys who smelled pretty bad (even though I exactly matched that profile myself :).

I really liked the contrarian groups who faked a lot. In Nooon's "Stars" (1995) a 3D bee is rendered with a complete wing missing, to fake a high poly count. "Transgression 2" by MFX may also be a good example of what I am trying to convey here. Obviously it was not real-time ray tracing, but what was it? It puzzled me for weeks!

The major category for demoscene competition has always been a more or less "no constraints" category. The restricted ones are really just so that smaller teams with fewer resources or different angles have the ability to compete as well.

The demoscene was once the birthplace of elite programmers.

I could write more or less a whole book on various demosceners and what they've done since (RTX, Media Molecule, modern tile based GPU architectures, visibility culling middleware in most games, music library used in most games, on and on, ...)

I would buy that book.

Nostalgia

1g constant acceleration is enough. But we don't have the technology yet.

thank you, but no. Short it yourself.