Which claims do you think are poorly supported? I'm the author; I tried to include everything other people need to repeat the same experiments. I've even had two people write in directly to me, stating that they have been able to replicate my findings.
Or are you referring to the claims from Meta, Google, and Adobe -- which failed to hold up under independent evaluation.
You are also correct that one of the meta authors wrote in a comment. However, he demonstrated a clear lack of understanding regarding what makes the bits "independent" or how to resolve the independence problem.
I can understand zip, 7z, and tar. But RAR? My only experience with RAR files comes from malware and warez (illegally distributed software, often compromised). Perhaps my own experience is just biased.
(B) Unexpected single point of failure (like a critical piece of hardware) and they need to rush-order a replacement.
(C) They can't identify the cause. (Doubtful.)
or
(D) Cascading failure. When they fix one thing, something else takes them down. Like a large queue of pending jobs that floods and crashes them when they come back up.
On one hand, I'm glad I don't depend on Square for purchases.
On the other hand, who's to say that my own payment provider can't have this same kind of problem?
Disclaimer: I'm not an attorney and this is not legal advice.
1. Can you claim that GPT are your initials? (Is your name George Patrick Tanner? Gina Parker Taylor?)
2. If you are using it for AI, then you're not going to be able to show that "GPT" is a term of art predating their company. The first appearance of the term for AI is from a paper by OpenAI.
3. Check the dates. Did you register your domain name before they filed their patent/trademark? (They filed in on Feb 3, 2023.) If so, then you have an argument for prior art.
4. Don't make an offer to sell (even in jest) without talking to an attorney. They could interpret it as a bad-faith negotiation and take the domain.
5. Do you plan to use the web site for something unrelated to AI? Information about GUID Partition Tables? Goniopora Toxin? General-purpose technologies? Generalized probabilistic theory? Grounded practical theory? Anything like this doesn't compete with their trademark.
I have been so incredibly impressed by System76. Professional, easy to work with, open source, and great quality. I used to run a Dell-only shop, but my last few systems have been System76. (Oh, and they don't spam you ever few months like Dell.)
Not a paid advertiser. Just a very happy customer.
Even if you have SPF and DKIM working correctly, they will block your email to outlook, hotmail, and other services unless you fill out their form. If you fill out the form, then you still need to wait months before they decide whether to accept your email.
On my own servers, I warn users who try to use hotmail or outlook that my email to them may not work and they should use a different email address.
This sounds like the same argument used when sites went after PirateBay for hosting pointers to content, even though they never hosted the content itself.
(A) A sudden last minute huge influx of "No" votes. Either caused by bots or by Musk putting his finger on the scale. (Yes, I think this voting will be rigged.)
(B) He already has someone in mind for running Twitter. That person will be as bad or worse than he is. (What's DJTJ doing these days?)
(C) He will claim that 'liberals' and 'bots' forced a "Yes", so he'll remove those votes.
> Tor never claimed that it can hide if somebody is using tor.
Not true. Pluggable transports are explicitly intended to prevent someone from seeing that you are connecting to Tor. This is because someone seeing you connect to Tor means that they can block your access to Tor, or monitor when you are using Tor.
The problem is, EVERY pluggable transport is trivially detectable. And of all of the pluggable transports, snowflake is by far the easiest to detect. The current suite of pluggable transports are nothing more than a security facade. I wouldn't even call them "better than nothing." If you are in an environment that requires bridges or pluggable transports to connect to Tor, then using them becomes easily detectable.
I had a similar experience with PayPal. Fortunately, I had created a separate bank account specifically for use with PayPal. After they blocked my account (for the heinous crime of having the word "Hacker" in my company name: Hacker Factor), I went to the bank and closed that account. PayPal ended up keeping the remaining balance of something like $1.
There are a lot of better-than-JPEG and better-than-PNG solutions out there.
Speed: If the benchmarks are correct, then this is exceptional, especially considering that the file size is only slightly larger than PNG.
I can think of a couple of ways they could reduce the file size by probably around 10%-20% without sacrificing speed, but this is good enough to get attention.
The biggest speed loss for PNG comes from zlib.
PNG without zlib is very fast -- probably comparable to QOI.
If QOI use bz2 or even zlib on top of the current encoding scheme, then it would be slower, but I bet it would also be smaller than PNG.
The biggest issue isn't making a better/faster picture format.
Rather, the biggest issues are adoption, metadata, and variable color support.
Until web browsers and smartphones natively support the format, it's only good for a proof-of-concept or for niche applications. (Don't get me wrong -- online games could benefit from something like this.)
Wide-spread consumer adoption will also need support for metadata. EXIF, IPTC, XMP, ICC Profiles, etc.
This is easy enough to add. I hope the author choose something simple, like a tag-length-data. The tag just identifies it as a meta block. The data should begin with a text string and "\n" that defines the type of data, followed by the binary data. The "length" includes the size of the data + string + 1 for "\n". Also, be aware that some metadata is larger than 65535 bytes, so the length should support large data blocks.
The algorithm as currently defined only supports 8-bits per channel and 3 or 4 channels (RGB or RGBA).
For widespread adoption, it should support:
- 8-bit Grayscale (1 byte per pixel)
- 16-bit Grayscale (2 bytes per pixel)
- 8-bit Grayscale + Alpha (2 byte per pixel)
- 16-bit Grayscale + Alpha (4 bytes per pixel)
- 8-bit and 16-bit RGB (24 and 48 bytes per pixel)
- 8-bit and 16-bit RGBA (32 and 64 bytes per pixel)
- 8-bit and 16-bit CMYK (for the printing industry)
- 8-bit YUV (for cameras; most also support 16-bit YUV, but it's rarely ever seen)
I don't think the algorithm will change for these, but the file format will need a header that defines the color space and color depth.
The source code is also problematic. For example, the .h (header) file contains functions. Not function definitions, but actual functions. E.g.: https://github.com/phoboslab/qoi/blob/master/qoi.h
All functions (qoi_encode, qoi_decode, etc.) are completely included in this header file. It should be in a .c file (not .h) and compiled into a library (libqoi). Although C does permit you to put functions in header files, it is REALLY REALLY REALLY bad form and strongly discouraged. (This is a really bad programming practice. When I was in school, doing this sort of thing would be an immediate homework failure even if the code works.)
All perceptual hashes, including AI-based perceptual hashes, have a "projection" property. If you have the hashes, you can project them into some kind of image. Some hashes result in blurry blobs (pHash, wavelet hashes). Some result in silhouettes (aHash, dHash). And some show well-defined images (PhotoDNA).
We don't know how Apple's solution works. But if it can project recognizable images, then it means people can use Apple's hash system to regenerate child porn.
Without details and an actual code review, I'm not willing to accept Apple's assurance that an image projection isn't possible. We hear that same promise from Microsoft's PhotoDNA, and it turned out to be false.
Imagine the problems if every iPhone and every Mac was in possession of child porn because Apple put it there...
Yes, this is a lot of 'if's, but until it has been evaluated, it is in the very real realm of possible.
Apple's recent CSAM announcement does not use PhotoDNA. Apple is not using PhotoDNA's hashes. Apple is using a different system called NeuralHash.
NCMEC operates like a roach hotel: CSAM goes in, and it only goes out to law enforcement. I am 99% certain that Apple never received CSAM material from NCMEC for training. While Apple's people may have sat in NCMEC's building for meetings, I doubt they were ever shown any actual CSAM. I've been told that NCMEC used a tool by Apple to create hashes for NeuralHash. The hashes are based on some number of "the most common" CSAM content. (In the past, "the most common" was around 30,000 files.)
In effect, Apple may not know what is in their trained data set. However, researchers (not me) are already looking for ways to extract data from the libraries. I think it's only a matter of time before this becomes a much bigger problem.
Or are you referring to the claims from Meta, Google, and Adobe -- which failed to hold up under independent evaluation.
You are also correct that one of the meta authors wrote in a comment. However, he demonstrated a clear lack of understanding regarding what makes the bits "independent" or how to resolve the independence problem.