This is a quirk of the last gpt image model (gpt-image-2). It put this sort of high frequency noise on all of the image especially if it's in a "drawn" style. There is often lots of other tells that this model in particular generated it.
Image models somewhat watermarking the image in a way that's very easily identifiable by a human seems present in all the image models of the big labs, since DALL-E 3 on OpenAI's side and the first nano banana on Google's side. I have no idea what they did to reach this and why they don't try to fix it.
I do AI assisted images for fun and browsing their art I can't see any tell of AI or even tracing on AI; people became paranoid and jump to conclusion without any substance and I find it sad that people who put a lot of time and effort into their craft are getting knee jerks comments like this.
> people became paranoid and jump to conclusion without any substance
Before AI, the only question was who made a particular artwork. Human-created practically a certainty.
When AI-generated art was new, it was all exiting & the process described to boast about AI capabilities or the skills of people deploying AI. But human-created still the default assumption.
Now, AI-generated <anything> is everywhere, and that default assumption of "human-created" is often questioned.
The natural next step is "AI-generated" as default assumption, unless claimed / shown (or even proven) otherwise.
Imho: assumption is the root of all evil. Investigate! Or take an author's word for it unless they're shown to be a liar. But as another commenter noted, it's a kind of tragedy of the commons. Methods to prove you as a human created <artwork> will be a thing.
> I was put off by the overly dramatic presentation. It gets tiring that the author apparently finds this more exciting than I do, and writes like it's enthralling.
That's one of the main tells that AI wrote this. All the stylistic tics that people usually point out combine to make the writing seem more important than it is.
Good question. I personally doubt that the compress instruction is easy to coax compilers into generating, as there are many edge cases to consider.
For example, you'll notice here that we perform a full vector store of 8 elements unconditionally, even if only a few of the elements are active. This is safe, though, because the output buffer is as large as the input buffer, and we're chunking by 8, so we'll never trash memory past the end; but this is a tricky analysis. Performance-wise, we rely on the CPU's store buffer to make these overlapping stores cheap.
Instead, you might think that you could just store the elements which are actually active, using a masked store. In fact there is also an intrinsic for this purpose (_mm512_mask_compressstoreu_pd), but it is extremely slow on some CPUs, namely Zen 4, so it's dangerous to use unless you know exactly what CPU you're using. (In my testing, there also seems to be some weird hazard on Zen 5 where multiple memory-destination compress instructions to nearby, even non-overlapping, addresses are serialized. But I haven't looked closer at this.)
I think WUFFS "iterate loops" might help. WUFFS requires that processing a chunk of N items has code to process one at a time, which means it'll work for any N. However you can optionally provide specialisations for doing K at a time and the compiler is responsible for carving the input up as appropriate so e.g. N = K + K + 1 + 1 + 1 your K-at-a-time code runs twice, the extras are handled 1-at-a-time.
So this divides up the problem, the compiler can vectorize your 8-at-a-time code without needing to handle edge cases where N isn't a multiple of 8, and if a later pass notices we actually never end up using those edge cases they're dead code, if it doesn't they're just a rarely-taken branch once.
I believe the bounds check, in particular, is devastating for autovectorization. There are ways around it, but it requires additional code in safe rust.
Edit: actually looks like autovectorization is in play here [1]. Doesn't look like the bounds check gets in the way at all.
Compress patterns aren't recognized by any open-source compiler autovectorizer as far as I'm aware of. (I think intel's proprietary C/C++ compiler can?)
Someone posted their AGENTS.md some time ago, that is used in practice to teach their students[1]. That might be useful to you in this context as well.
as temperature approaches infinity, min_p must approach 1 to stay coherent.
Assuming your temp is below 2, min_p of 0.1 is fine (and disable top_p and top_k). You can try 0.05 for more diversity.
Remember that subsequent methods are better, min_p is a mid-tier sampler that just happens to be the best implemented in most inference providers right now.
Also I'm the author of the "conspiracy against high temperature sampling" thing that selfhoster posted in the comments, so you can ask any questions about that piece you want.
You can't treat it with opioid agonist therapy (buprenorphine, methadone, ...) to suppress the withdrawals like you would with most other cases of opioid dependency?
That's my understanding. I knew a guy that went through that, and basically they tried to treat it with opiate protocols and it didn't really work, and you have these overworked nurses that unfortunately just don't really know what to do there. Usually opiate withdrawal isn't as dangerous as like benzodiazepine withdrawal or alcohol withdrawal (which can kill you), so I don't think it's likely to kill most people, but it seems like a pretty awful experience I wouldn't wish on my worst enemy.
reply