Students are failing AP tests because the College Board can’t handle HEIC images

HEIC isn't supported in a lot of places. It's mainly (only?) Apple that uses it with iOS devices.

Perhaps Apple should make it easier or automatic to convert into a format that's universally usable.

Bet the same thing would have happened with webp images too.

JPG and PNG are like the FAT32 format of images. Always accepted, everywhere.

> Perhaps Apple should make it easier or automatic to convert into a format that's universally usable.

Further down this thread you’ll see that the board have messed up and they aren’t accepting images they should due to poor implementation.

“ oefrha 1 hour ago [–]

Tried a standard input tag with the proper accept attribute <input type="file" accept="image/jpeg,image/png" /> Selected a HEIC file from Photos in Safari, the selected image was automatically converted to JPEG”

I'd posit that Apple ought to assume the worst (ie nothing but JPEG and PNG is supported) if no format is specified. That's how we've built most of the web, to ensure backwards compatibility and avoid these kinds of problems.

That said, come on College Board. Fix your crap. What a stupid bug.

As I understood the article, the problem did not arise when uploading the picture directly from the phone, but in cases in which the picture was first transferred to a computer (via Airdrop was explicitly mentioned, but could probably also have been a cable connection) and then uploaded from the computer. Whatever conversion the browser on the iPhone (or Safari on macOS, because there are other browsers on computers as well) does or does not do is irrelevant in such a situation.

You know, I thought that about FAT32. But apparently neither Windows nor Mac OS X can see a FAT32 partition on an SD card if it's not the primary partition (at, least, not in an obvious way).

My understanding from the article was that both types of problems happened.

Don't think that's exclusive to FAT32. For quite a while Windows just straight up ignored anything but the first partition on removeable media.

If no format is specified, then the presumption would be that the website wants a raw octet stream, and that adulterating it would be the last thing a client device should do, because it knows nothing about what the website's going to do to the result.

Windows and macOS do that in order to hide EFI system partitions, I believe. (Not that they should have to; MBR and GPT both define a specific tag to mark a partition as being an EFI partition. But so many partitioning tools don't bother to use that tag—or to adhere to any other standard that could be used to identify an EFI partition—that OSes are stuck with a very bad/loose heuristic.)

They may also get some other benefits from this bad/loose heuristic, e.g. hiding Linux's common FAT32 /boot partition; OEMs' "backup" and "BIOS update" partitions; OS Recovery partitions from unknown (and therefore unpredictable-in-approach) OSes; etc.

What the consumer OSes really need is a bit in each MBR/GPT partition's bitflags, that has a meaning equivalent to one of those "no user-serviceable parts inside" stickers. I think it's too late to fit that bit into either standard, sadly.

Do you have any idea what that approach would do to bandwidth and latency?

Er... what?

By "raw octet stream", I meant that the client should upload a file named X made of opaque bytes 0xABCD, as a file named X made of opaque bytes 0xABCD; rather than assuming a higher-level intent on the server's part to acquire some abstract document, where the client would be able to better serve that request by transforming its file to a different file-format.

I didn't mean that e.g. the client should avoid using Transfer-Encoding compression during the HTTP POST request, or anything like that. (That is, after all, a fact about the wire representation of the request; it doesn't affect the file received on the server end.)

Or, to put that another way, an <input type="file"> with no `accept`, is to the client, as `Cache-Control: no-transform` is to the server: an expressed desire to get some specific data that exists the other end sent over "as it is", rather than to get something customized to the peer's needs.

My apologies. I misread your intent.

I thought you were suggesting that images should be sent as raw octets for the image, rather than picking a compression format. But that raw data is extremely large, and therefore would have horrible impacts on bandwidth and latency.

That said, you're right. Trying to be clever about what people are sending results in a lot of hidden complexity and bugs of various forms.

Okay, but the contents of that raw occlet stream will be a file in some format. The iPhone isn't like a traditional computer—the user picks an image from a library of images, and the type of image is abstracted away. Yes, it so happens that modern iPhones store images on disk as HEIC, but since this isn't user-visible it amounts to an implementation detail.

Since the user didn't specify a format, and the website didn't specify a format, the iPhone needs to guess something. Seems to me it should guess the format that's most likely to work, not the one only a tiny number of devices support.

I agree with it, at least for a few years.

But the website did specify a format. Like I said in my sibling comment, a lack of an `accept` attribute (which is the same as saying `accept="⋆/⋆"`) has a conventional meaning from a plethora of legacy use-cases; and that meaning is:

"Give me the underlying data, just as it is. You may or may not understand what it is, but I'm asking you to pretend that you don't, because I definitely don't understand what it is. I'm acting as a courier on behalf of a recipient who wants whatever you give me. All they told me was to get it from you. Please don't try to guess why they want it, or to prepare it for them in some way. Their motivations are beyond our understanding. They just want it. They want what you have, the way you currently have it. Do as little to it as possible, because anything you do may be counter-productive to their unknowable designs."

This is, for one thing, the use-case of file-sharing websites. If you upload something to e.g. MEGA, or WeTransfer, you're doing that in order for something further to happen to it on the other side. The other side may or may not have wanted the file in its original format, but that question is up to them, not up to the sender. The job of a "dumb pipe" file-transfer service, is to take what it's given, and losslessly pass it on to the recipient, so that further steps can happen. And, as such, it's also a responsibility of a file-transfer service to ask the User-Agent to also send the file on to it losslessly, because in this case the User-Agent is also acting as part of the "dumb pipe" transfer process.

Let me put it this way: if my photos were not saving correctly, and someone at Apple asked me to file a Radar ticket and attach such a mis-encoded photo to the ticket... how would the Radar web-app express the intent of "I want the stupid mis-encoded file that you-the-device are using to store what you think is a Photos photo"? Well, our legacy convention is that it would express that intent through `accept="⋆/⋆"`. (Or a lack of an `accept` header at all.)

Note that this is different from an `accept` attribute like "image/⋆". In that case, we know something—we know that the recipient we're acting as courier has the intent to use the uploaded file as an image—so both the mis-encoded file, and maybe HEIC files, are probably bad candidates. One should be filtered out as an upload candidate; the other should maybe be transcoded (just like a RAW camera file would be.)