Hacker News new | past | comments | ask | show | jobs | submit login
Students are failing AP tests because the College Board can’t handle HEIC images (theverge.com)
669 points by danso 11 days ago | hide | past | web | favorite | 551 comments





A lot of comments are arguing about whether the software should have been modified to accept the HEIC format.

Let's go with "no" for the sake of argument. They probably can't accept an mp3 of me singing my answers, either. But!

If I upload an HEIC, an mp3, a keynote file, or anything else unacceptable... Why doesn't the site provide an immediate "File format not accepted, please upload .gif, .jpg, or .png" message?

According to the article, the software would actually just hang. I think there's room to argue about whether they need to support the default format of an extremely significant platform for students. I think there's room to argue whether they should know enough about INPUT tags to let the browser help with this.

But while we're arguing about those questions, can't we all agree that simply hanging without providing a useful error message, and without giving the student an opportunity to re-upload their image... Is unacceptably poor software design for an institution that holds people's future in their hands?

I don't know about you, but if I were an American college student, I'd now be wondering what else they have kind of slapped together without thinking through graceful error handling?


It does have pretty much exactly that message. The corruption problems came from students seeing that only PNGs/JPGs were allowed, then trying to "convert" the file just by renaming it.

What they're doing is the same as 99% of other sites that expect images. But it's probably fair to expect it to be even more streamlined (i.e: clear conversion instructions) given the circumstances of a time-limited exam.


No, what 99% of sites are doing is

    <input type="file" accept="image/png, image/jpg, image/jpeg" />
If you do that, Safari will convert the HEIC image to a JPEG automatically when you try to upload it.

What they did instead was to poorly reinvent the accept header in Javascript as follows:

    <input
      type="file"
      ...
      onChange={async e => {
        const split = file.name.split('.')
        const fileType = split[split.length-1].toLowerCase()
        const isAllowedExtension = extensions.includes(`.${fileType}`)
      }}
    />
(per https://news.ycombinator.com/item?id=23261598).

That might be part of the problem, though other comments also point out that students were copying file to a computer, then changing file extension, then uploading. Possibly this was as a result of the iOS browser rejecting the file in the first place due to the shoddy input filtering mentioned.

But going a bit bigger picture, the problem is that we still use file extensions to denote file type.


This keeps getting brought up because there was one anecdote in the Verge story about a student who renamed the file on their computer. (Which still shouldn't have caused the test to keel over, but it's at least slightly more understandable.)

However, there were many other reports of students going the more "normal" route of just uploading through their iPhones, which caused the website to outright hang.


> If you do that, Safari will convert the HEIC image to a JPEG automatically when you try to upload it.

That’s quite impressive actually and much more than I would expect from a browser’s <input type=“file”> control.


It's also not what a browser should do.

JPEG conversions will vary in quality and size. On some sites (e.g. a CMS), quality can be sacrified to stay within file size limits.

On other sites, like photo printing services, quality is much more important.

These may be unusual cases, but silent browser assumptions are still an overstep.


There's nothing stopping the user from doing a conversion themselves if they want to (and know how, which is asking a lot).

The server is saying it can't read the other file type, so the alternative is to fail.


There's a medium option: have an alert popup saying

    Convert the image to a format the site accepts (jpg)?

    [ ] Don't show this message again

    [OK] [Cancel]

Anecdotally, yesterday I accidentally learned that my relative clicks OK in any dialog window within 200ms without even attempt to read the message. So the alert you suggest would slightly help 1% of geeks and will annoy 99% of the users.

Compared to the option of not converting, it would help everyone, reducing annoyance.

Also I'm not sure if you can generalize from your one relative to 99% of users.


While it may not be 99%, /r/talesfromtechsupport on reddit has enough instances of this to suggest it is extremely common user behavior.

Just to give credit where it's due here, I don't think I've ever seen a client side form check upload sizes before. I've had many frustrations going through a form upload then refreshing to a page that says "your file was too big".

Most other sites would accept the upload, try to parse it and then return an error message. Its always the sites fault if it just gets stuck

Eh that's not often a good idea. The service should only look at the file header for the mime type and decide based on that if it should even begin to upload.

Mime types can be spoofed and if you read the data blob's mime from its' type, then just an extension rename will fool it. But if you look at the magic numbers you're saving your server's resources and the uploader's time as it doesn't even try to move the file if the mime is not acceptable. No reason not to do it on the client-side first.


> The corruption problems came from students seeing that only PNGs/JPGs were allowed, then trying to "convert" the file just by renaming it.

I mean ... isn't that kind of a classic trick when handing in homework you didn't make? Just rename some file to .doc and claim it got corrupted?


File extensions have terrible usability. People changing the extension expecting something to be fixed is a classic misunderstanding. Many people do this every day, decades into personal computing.

I don't understand why no one is blaming the education system?

How is it possible that students that are being considered for "advanced placement" are not familiar with file formats?

how horrible and backward your education system must be? This belongs to basic literacy in the modern world.

Note we're not speaking about old people who were exposed to files for the first time while they had to balance a family life and other responsibilities.

We're speaking about people that were forced to spend more than half of their lives learning !!!


Because in a world where apps do everything for you and 80% of your use is on a phone and the remaining 20% is either for a once a year use case, you don't need to worry about image formats.

Even as a software engineer, I haven't used a desktop or windows in 5 years. I haven't used TheGimp (or any other non web/app image manipulation software) in 3 years.


that's interesting, so you use an iPad for your day to day programming?

from my experience converting ppt/word to pdf is a common enough use case that I would've assumed the majority of non-tech people run into it.

Latex is also a common case where you run into file extensions.

note I'm not expecting them to understand the difference between extensions, just what they mean and how to google how to convert between them.


They don't learn any critical thinking skills. Memorization != learning.

It should go a bit further than what you're suggesting even. Any half-serious upload of a document or image now, less high stakes than a CB test, generally displays the file you upload for you to verify. Ie, "here's what we have from what you uploaded. Is this ok?"

The college board should have had a list of accepted formats, should have included instructions that they put in the tweet in the upload UI, and should have had an uploaded document verification process. This is solely the responsibility of the CB, and is deceitful at some level, by leading students to believe they were complying when they were not.


Just think, with this level of incompetence here, how much are these tests actually worth?

    else if (!isAllowedExtension)
         error = { title: 'This file type is not acceptable.', details: 'Please check the requirements, save your file in one of the accepted 
    formats, and resubmit.' }
Or, maybe theverge is just lying or relying on the misconception. If you think renaming your file is the same as converting your file, maybe you are misplaced in the advanced placement program...

It’s amazing to me that so many are blaming Apple. Despite the fact that this site is all about new technology (so ironic!), uploading a photo from an iPhone isn’t exactly an edge case. They should have tested this, and apparently they did enough to send a tweet about it.. as if that’s enough. Clearly the college board dropped the ball in adequately informing people of their not-great workaround, instead of either specifying the accepted types directly in the web page’s input tag (as many have pointed out, and thus would have just worked correctly in the background), or by accepting and converting HEIC files themselves. At minimum, they should have put their suggested settings changes into the webpage itself before you started, and/or given a practice website to make sure it worked correctly.

College board owns this process, and it’s their job to make sure the setup works correctly for all students, including those who might not all be technically inclined.


Using HEIC apparently [1][2] requires a license and is patent encumbered[3], so I actually blame Apple for using a closed format by default.

[1] https://forums.developer.apple.com/thread/97036 [2] https://news.ycombinator.com/item?id=17587923

[2] http://www.hackerfactor.com/blog/index.php?/archives/833-HEI...


First of all, as many others have pointed out by specifying the accepted file formats in the <input> tag, they would avoid HEIC entirely as the phone would simply convert to one of the accepted formats.

It's also not clear to me that this patent license is actually an issue in terms of decoding and converting file formats on the backend. Even if that were the case, I'm certain there is some commercial license software they could purchase to do that for them. This isn't an open-source endeavor, and they charge each student to take the exam.


1. I think both parties are at fault

The testing system for not using the <input> tag appropiately and Apple for using a closed, patent encumbered format as the default when most of their users don't know about software patents.

> It's also not clear to me that this patent license is actually an issue in terms of decoding and converting file formats on the backend.

It's reasonable to assume that it is.

2. Sure, the college could pay, but looking at the broader problem here, saying that colleges should accept closed formats would make it really hard for open source online testing systems to proliferate, and all colleges around the world would have to pay royalties to the HEIC patent holders.

Even if they were to implement an open source decoder, unless you have plenty of lawyers, the legal uncertainty of the situation could be unacceptable to many individuals/institutions.

3. If the format was open in the first place, maybe we would have lots of open source decoders and maybe the library that the testing system developer used would have support for it, and would have transparently worked without the developer knowing about the format.


1. I'm not going to argue about Apple's defaults here. It simply isn't germane when the college board has full control over the inputs and iPhones will make up a significant portion of test takers.

2. I think you don't understand what the College Board is. It's a single organization that administers test. This isn't something each university needs to deal with. They make and administer the test to all college-bound students in the US each year.

3. There are plenty of existing open source decoders, and all major open source graphics programs already accept the format (GraphicConverter, ImageMagick, GIMP), in addition to all the major OSes (Windows, Mac, iOS, Android).


2. In the specific case of the College Board, yes. Keep in mind that maybe the license fee is based on number of institutions and every student would end up indirectly paying for the license.

But also think about independent educational institutions (primary, secondary, higher, etc), think about all schools and colleges in other countries (we're all in a similar situation). All of them would have to find a way to license HEIC, just because Apple decided that they wanted HEIC as their default format.

3. I'd guess that companies that implement HEIC pay for their license.

The legal situation of using open source programs to decode licensed and patent encumbered formats is uncertain to me, and I guess it is to most people, including software engineers and managers.


No other entity other than The College Board receives the raw test. Everyone else only receives the results. The College Board also charges around $100 for each of these tests, so even if they had to support the format (they don’t) they really should easily be able to do so.

Note that many students take many of these tests, even dozens, so $100/test is quite a lot for what is usually a few hours sit down in a big room with a handful of proctors for hundreds of students (i.e., no more expensive to run than a typical university intro-level class final with a professor and some student TAs).

The whole issue is easily circumvented by correctly setting the accepted inputs, which is clearly the responsibility of the webpage owners. Next time, someone uploads JPEG2000 and runs into the same problem. I guess then it’s again someone else who gets the blame?

The license fee is based on the number of devices performing the conversion; each institution gets a number free; it's less than a few dollars per device.

If the iPhone took pictures in webp format, exactly the same thing would have occurred. College board doesn’t accept that either despite it being open.

webp is also possibly patent-encumbered. At least if you ask various members of the MPEG-LA.

The only safe format for photo-like content remains JPEG probably for decades to come


Yes, I was wondering why a recently completed photo upload feature for a web app didn't have this problem -- it's because we specified image/jpeg on the file input, so iPhone auto-converts. Likely a failure within the college board's software engineering processes for not testing this use case and then finding and deploying this fix? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Some of the issues seems to be because some of these students transferred the HEIC file to their computers then tried to upload them by changing the extension of the file.

Wait. There's a way to get safari to upload HEIF without conversion? All my photos, which are HEIF on my phone, turn into jpeg when I upload them. I've been trying to get the original HEIF off for months.


Dropbox and OneDrive allow you to sync HEIF instead of JPEG.

Only native apps that explicitly opt-in to HEIC support.

Do I really need to explain that if I upload a file to Dropbox or iCloud it's still not on the web site form where I want it?

Google Photos syncs HEIF/HEIC to their cloud.

If you don't use your phone to upload, but transfer the file to your computer, it won't do the conversion.


Patents are separate from copyright, so even an independently developed freely licensed open-source software is illegal to use without a patent license from patent owners.

https://www.hevcadvance.com/pdfnew/LicensorList.pdf


Assuming GP is right about the patents, the College Board would open themselves up to patent suits by using that without a license.

Maybe they should just pay the $5 fee...

So what formats do they accept when they want a video? Theora?

>Using HEIC apparently [1][2] requires a license and is patent encumbered[3]

College board could have added "iPhone HEIC license surcharge" for those users - that would have gotten Apple attention :)


> uploading a photo from an iPhone isn’t exactly an edge case

From what I've heard in articles and other sources, uploading directly from the iPhone works fine. The issue is only when students try to upload an HEIF file from a computer, instead of directly from an iPhone, which requires:

1. The student has an iPhone, which they use to take a picture of their work.

2. The student chooses not to upload directly from their iPhone, and instead wants to use their computer (presumably they're already logged in there).

3. The student's computer is a Mac, and they choose to use AirDrop (or another method that doesn't do conversion) to transfer the file instead of email (or another method that does convert to JPG).

4. The student is using Chrome/Firefox or another browser that doesn't do automatic conversion to JPG.

I would argue that this qualifies as an edge case. Presumably, CollegeBoard did their due diligence testing the basic single-device flows, but didn't cover multi-device flows, or just missed possibilities like AirDrop instead of email for transferring images.

I agree that they should have done a better job informing students; there probably should be more info on the upload page itself.


If your premise was true, then they wouldn't be tweeting this: https://twitter.com/CollegeBoard/status/1263484343084867586/...

Clearly they knew this would be an issue, and could have done multiple mitigations to handle this, including just accepting HEIC files themselves.


That really doesn’t sound like much of an edge case to me. I’m willing to bet it’s a pretty typical workflow that people have if they own Apple devices.

You would be surprised how many students use an iphone and a macbook but are unwilling to use safari (or icloud, photos) because of privacy concerns.

If you stay in the "regular" apple workflow everything is fine: iphone camera -> icloud/photos (airdrop/photos) -> safari. If you deviate at certain points though the workflow breaks down. Whose fault is that?


A (high school) student who's unwilling to use Safari because of privacy concerns but would be ok using Chrome? That sounds like a serious edge case.

Sadly, it's not. I've had lots students who would use the Opera VPN or one of the "free" anti-virus providers VPNs because they got sold (by adds or dumb friends) that it would be safer.

You seriously over-estimate the "tech-savviness" of the average student and that really is part of the issue I'm pointing out here.


I can confirm. The average graduating high school senior or first-year college student is woefully inept at technical tasks. They grew up with tablets and smart phones, but outside the common apps, they aren't any more tech-savvy than anybody else.

Source: I work in tech for higher ed.


For their threat model, they could be right - they could be successfully defending against school network surveillance and/or censorship.

Mobile uploading is often broken or inconvenient. Phone to sync service (such as dropbox or icloud) to desktop with a full functioning browser to upload. This doesn’t seem like an edge case to me. I’d expect uploading directly from a phone to be an edge case. Most people don’t want to waste time filling out forms with a touchscreen when they have a mouse and keyboard handy.

This whole blame game is weird. Could the college board have handled this better or have a better upload mechanism? Sure. Could apple be more clear about the way they are storing and transferring photos? Sure, finder on my macbook actually does worse in handling .heic files than my windows 10 desktop unless I sync using photos.

But if I got this right the upload page stated the accepted file formats, why should they accept anything else? Sure, there are workarounds to handle uploading .heic files and automatic conversion works in certain cases but why should they care? The onus is on the user to ensure his submission is correct.

EDIT: I just tried .heic files on my Surface and had to install an MS store app to actually be able to open .heic files in full resolution.

https://www.microsoft.com/de-de/p/heif-bilderweiterungen/9pm...

EDIT2: I guess for me it boils down to, why should we coddle the applicants? Being able to understand the conditions of a test is not an unreasonable hardship. From that I gathered the website stated the accepted file formats. The uploader source suggests it did refuse certain file formats. There are technical solutions for this/these problem(s) and of course it would be nice if every system would be perfect. But it would also be nice if people would just work within the given constraints of a system.


If I may restate your position: "If a student uploads an image in the wrong format then it is acceptable for their entire test to be invalid and they can retake the entire exam."

Rather I think what is acceptable is HEIC is not accepted by the system, and if a student attempts to submit this format they receive an error saying that only JPG images are allowed.


> If I may restate your position: "If a student uploads an image in the wrong format then it is acceptable for their entire test to be invalid and they can retake the entire exam."

Yes, being able to understand the conditions should maybe be part of passing the test. Like I said, could the upload form have handled this better? Sure, although I have not read enough to understand if this was actually the upload form failing. The OP article claims "Spencer ... tried to convert it by renaming the HEIC file to PNG" which is not how you convert files. Maybe students learning that early on is not a bad thing?


> Yes, being able to understand the conditions should maybe be part of passing the test.

I agree, when It's part of the subject in test. I don't see any reasonable cause for a student to have to know about file types to submit a test, if that test isn't about file types. I don't, for example, expect my doctor to know how to convert an image file because that's not his job.

> The OP article claims "Spencer ... tried to convert it by renaming the HEIC file to PNG" which is not how you convert files.

This highlights the level of knowledge the users of this application have in this area. The developers should have made it Painfully Clear that uploading directly from an iPhone isn't supported.

> Maybe students learning that early on is not a bad thing?

I agree they should learn this stuff, but don't think it should cost them their grade to do so.

Now, I'm not saying that we shouldn't increase public understanding of these "slightly-technical" topics but I think we're a long way off and we can't expect that understanding just yet.


>I agree, when It's part of the subject in test. I don't see any reasonable cause for a student to have to know about file types to submit a test, if that test isn't about file types. I don't, for example, expect my doctor to know how to convert an image file because that's not his job.

Understanding the conditions of your test is part of the test. And your doctor doesn't have to know. His toolchain forces him to use certain programs and settings. If anything is set up wrong, your MRI image is just a worthless CD-R.

>This highlights the level of knowledge the users of this application have in this area. The developers should have made it Painfully Clear that uploading directly from an iPhone isn't supported.

They did. The supported file formats were clearly stated. Your issue here is with apple.

>I agree they should learn this stuff, but don't think it should cost them their grade to do so.

It doesn't. They can retake the test without punishment.

>Now, I'm not saying that we shouldn't increase public understanding of these "slightly-technical" topics but I think we're a long way off and we can't expect that understanding just yet.

I disagree. The sooner people learn that renaming a file does not constitute conversion the better. When I was a student 15 years ago it was painfully clear you could not upload the 50MB .tif file your scanner spat out (silly websites at the time would just not take 50MB uploads most of the time...). I think this "slightly-technical" knowledge is something akin to correct spelling and grammar. It's fine if you disagree but, in my opinion (even if that was not the intent of the college board), this is not a bad lesson to teach.


You're still supporting that computer knowledge of what image file formats are and how to convert them should be part of the test. They can learn that later when their high school or college makes them take basic computer classes (hopefully), right now they just want to upload their image.

Either Apple or College Board is at fault here but it isn't the user.


Yes, if you want to use a cell phone and/or a computer to complete your tasks you should have some basic knowledge about how it operates.

You can shift responsibility for that knowledge wherever you want but I would say that at the age between 16 and 19 (which google tells me is the average age for AP classes) I would expect that knowledge from someone applying for AP credit. And if someone didn't know what the accepted file types (as stated in the FAQ) meant at that age I'd expect them to figure it out for themselves.


I'm unsure that any of these students wanted to take their AP exams on their phone or computer. That this is a new problem suggests that this is something they've been newly forced to deal with.

It's certainly not a well engineered user experience. Passing a physics test should require physics knowledge, not knowledge of image formats. I think understanding of image formats is actually fairly obscure outside of technical circles.


[flagged]


No one rational feels sorry for universities.

No one rational makes absolute comments on the internet.

Maybe university IT departments are staffed by people. Maybe even at the college board it's just some IT guys trying to keep a shitty platform working. Maybe they did the best they could working within their constraints and they expected the same from students who have a vested interest in getting their results submitted. Maybe this is just much ado about nothing.


I don't see why you'd assume that the students did anything less than their best.

I'm pretty damn technical and I never heard of HEIC before today. Maybe I would have if I had an Iphone, but in general if I take a photo with my phone I assume it writes a JPEG to the file system somewhere. If that's not the case, the software -- not the students -- should have been able to handle the issue. Computers are the servants of people; not the other way around.

Is this for comment real? Why should being tech savvy enough to jump through esoteric technical requirements be part of the test?

Ever see a student get scolded for not using a #2 pencil? Can't use a pen. Can't use a marker. Can't use a #9 pencil. Must be a a #2 pencil.

Ever fill out a government form that must be done in non erasable black or blue ink. A pencil is unacceptable. A red pen, green pen, purple pen is unacceptable. An erasable pen is also unacceptable.

Not saying users should have to know what a .JPG from an .HEIC but just saying there is plenty of precedent of technical requirements for things in real life. I've had forms rejected at the immigration office for using the wrong type of pen an I've been in classes where students didn't have the correct type of pencil and caused issues.


ok but what if you're told this 'technical requirement' in a tweet while taking the test? and you don't even use twitter?

#2 pencils are standard student equipment. As are iPhones.

And government forms also come with pens to fill them out.


> esoteric technical requirements

Knowing a file type is an "esoteric technical requirement" ?

Yes, this comment is for real. I'm the head of IT for a university and we do online applications. We actually accept everything within a given size requirement (which people are unable to respect). I have a bunch of scripts that run over all applications in the end to put them in the right formats, to do OCR for the photos of a printed PDF form that has been filled out by hand in pencil, I even run a script to scrape annotations in PDF portfolios to scrape video links and pass them to youtube-dl, to ensure everything submitted gets picked up and is provided for evaluation.

This is why I think it would be nice if there was at least some responsibility on the part of the student.


> Knowing a file type is an "esoteric technical requirement" ?

Yes, when it is outside of the scope of the test. Unless they're testing the students on their knowledge of data storage, or similar, this is out of scope.


Well, I disagree. I think "media competence" is more important than spelling or grammar and should be something expected of someone entering tertiary education.

Well, I suppose you’re welcome to have whatever bizarre opinions you like, but you should recognise that they’re pretty fringe.

No, this isn’t something the average person should need to know about.


[flagged]


By default, both Windows and MacOS hide file extensions. Smart phones almost universally hide them, if they give you a file explorer at all.

I suspect most teenagers (and that's what we're talking about here - 17, 18 years olds finishing secondary school) would have a notion that jpg and gif are image formats, and pdf and dcx are a document formats. I suspect few would know much beyond that, and most would not have had much reason to worry about converting between formats. [I work in higher ed tech, my gut feeling here is based on performing usability testing of other software]

Add in an unexpected file format glitch during the most important test of their life? Yeah, I'm not at all surprised that some/many screwed up.

This is 100% on College Board for failing to handle the situation gracefully. They didn't need to accept heif files. They did need to provide detailed instructions ahead of time, including possible issues with unsupported formats.


> I suspect few would know much beyond that, and most would not have had much reason to worry about converting between formats.

Ok, first of, why should I (as an institution) care about the people unable to fulfil the conditions of my test? Maybe I only want people with a basic understanding of file formats because chances are they will have less issues with future applications?

> They did need to provide detailed instructions ahead of time, including possible issues with unsupported formats.

They send out a message a week before the tests. The website only accepted the allowed formats. You could complain about them using Twitter to send out that message but you are not.

> They didn't need to accept heif files. They did need to provide detailed instructions ahead of time, including possible issues with unsupported formats.

They did not accept .heic files (see the source from the upload js file). They did provide a list of supported files. Maybe the handholding should stop at some point?


It's not the institution giving the test. It's a for-profit corporation that has a de facto monopoly on standardized testing in the US. It's also a company who has been slow to modernize their test (both content, scoring, and process) and has slowly lost the faith of many colleges/unis. And the students are paying for the "privilege" because their test is the gateway to higher ed.

The at-home test format is new. It's usually given in a test center (either private or at the secondary school) with a proctor. Students usually prep for years for this exam, but all that prep would be for the on-site proctored exam. This was new for everybody, and appears to be poorly executed by the company that profits handsomely from these exams.

Based on the article linked, the message went out the day of the exam, after some students were already mid-test. That's not helpful.


> Ok, first of, why should I (as an institution) care about the people unable to fulfil the conditions of my test?

Maybe you (as an institution) care about all your students?


But that's not what the test is about. It's not a category on the test.

It's not an explicit category on the test and I never debated that. It might be an implicit requirement though.

Just how when you take your drivers test you should actually be able to operate your vehicle and know the laws around operating a motor vehicle aside from the explicit knowledge required from you in the test. But I understand how this might be a foreign concept for someone from the US.


> But I understand how this might be a foreign concept for someone from the US.

What? In the US, knowing how to operate your vehicle and the laws around operating a motor vehicle IS the drivers test.

Your argument is not reasonable. Knowing the nuances of file formats is irrelevant to AP exams in US History, Calculus, Physics, etc. This is a failure of the administrators to make a proper test. The College Board specializes in tests- that's what they do, and they screwed up.


[flagged]


Please don't cross into personal attack, regardless how wrong another commenter is or you feel they are. It just makes the thread even worse.

https://news.ycombinator.com/newsguidelines.html


Yes. Your average user knows nothing of file types. They know about pictures. Ask your average iPhone users whether their pictures are stored as JPEG, HEIC or TIFF files and you'll get a blank stare most of the time.

You’re vastly overestimating the competence of the average computer user. There’s a sizeable minority of people out there that don’t know what file extensions are, and even if they do know about them, they might not understand how they work (hence students attempting to convert file types by changing the extension).

File extensions are an implementation detail that, ideally, end users should never be forced to think about. There are graceful solutions to this problem; the College Board just didn’t do their due diligence.


I'm not overestimating them. I see lots of college admission files, I know how inept most high school graduates are. I would like to see a higher base standard because frankly these issues are not going away for them and I don't see it as a tertiary education issue. 3 to 6 years later they will still have to submit resumes and portfolios and they will suck at it but the places they submit these to now longer offer any grace periods. File size to large? Fuck you. Wrong file type? Fuck you. Unsigned PDF? Fuck you. Missing a document? Fuck you. Missed a dead line? Fuck you.

Many places don't handle those files properly. For selling on eBay/Mercari/Poshmark, if I AirDrop from my iPhone to upload from my computer, they don't convert the file properly. (Typing descriptions etc is far easier from the computer than on a mobile app) I can setup an Apple Script to do conversions, but I've found uploading to Dropbox and pulling from the desktop version works better (Dropbox does the HEIC-JPG conversion)

I believe the onus should be on the trillion dollar company that chose to use a non-standard file format.


What an embarrassment. Just let the students upload whatever file, run it through imagemagick on the backend and convert to JPEG or PNG. If the output if garbage then shoot them an email.

Compatibility with multiples browsers / platforms is usually the responsibility of the website/application.

Historically Apple has implemented what they want to out of various standards, protocols, etc, it shouldn't be a surprise.

Of course, it's not my preference when we're waiting for different operating systems or browsers to behave the same way, but that lack of compatibility has been going on for decades.


Closed/liscenced crap != innovation.

I don’t care which part of California it came out of.


Why does Safari still not support webp then?

"Our system broke, you're screwed now, sorry" is never an acceptable answer. Do they really not have anyone who knows how to get stuff done?

1. Take the files and figure out what to do with them so they can be read. This isn't a hard problem.

2. Ask everyone affected to email you the photo or a new photo of the documents. We'll just take it on trust that you do so honestly because there's no way you would've seen this coming.


>"Our system broke, you're screwed now, sorry" is never an acceptable answer.

That's not what happened at all. The college board admitted their fault and are letting students take the test again. Even without that, they mentioned in their FAQ that JPEGs and PNGs are the only file types acceptable and even sent out a tweet (which should have been an email) a week before especially for iPhone users to let them know how to take pictures as JPEGs.

I agree with the people blaming the board for not having a standard image input field that lets the OS know when to convert images to JPEG but that is their only fault and I wouldn't have thought of that as a bug deal if not for this issue. While I'm all for open source media formats replacing what we have, HEIC certainly isn't big enough to be considered as among standard input options. Also, isn't Apple themselves infamous for not supporting certain formats throughout their devices?


If they had enough time to warn people ahead of time, they had plenty of time to push a fix to their system for this. We are literally talking about adding support for one more image format.

Emails, tweets, texts are no excuse for broken products. The iPhone is the best selling model in the United States. It is on College Board to support its default image format.

Good product design is owning your users' success. It is not sending people workaround emails.

The bare minimum would have to be to do a warning before every single AP test about this and giving students a few minutes to change their default image format. Sending a tweet (!!!) out does not count as doing any work.

This is a failure. An abysmal failure.


Even more strange is that when the file failed to parse after uploading, they just threw out the files instead of keeping them to analyze later.

If they still had the uploads they could go back and convert them properly and apologize for the delay.

It's just bad engineering all around. Even if there was a less glaringly obvious bug that caused parsing to fail, how would they debug that parsing bug without a sample file?


I mean it's not that odd when you think about how software is typically written. The parsing logic probably threw an exception that was never handled and just pops everything uploaded off the stack by default.

I'm not sure how you typically write software, but I don't consider it typical for software that opens a file and encounters unexpected input to throw an exception and then delete the file.

If an exception is thrown and not caught, the software should stop doing anything.


As I said, the file data was likely popped off the stack automatically, no need to write any extra code.

In your model, what's happening to the data in the file system?

Uploads are often initially stored in a temp directory before they are validated and moved to wherever they are meant to be stored, and the default behavior in PHP, for example, is to delete uploads that are not moved or renamed at the end of the request.

In the scenario I'm describing nothing is ever written to disk. The uploaded image data is streamed into memory directly from the socket and is processed in situ, when an exception occurs the stack unwinds and deallocates the memory storing the image data.

Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.


But it is incredibly unlikely that web uploads are piped directly into custom software rather than just being written as files which are processed later. That would be an extreme amount of extra work for no benefit at all.

Tomcat gives you a http request object where you can just grab the input stream object and pass it to pretty much every library that processes files because opening a file just gives you a fileinputstream so adding general support for inputstreams is much easier than actually adding support that only works on files.

It's not at all unlikely, this is the default behavior for various setups, e.g. nodejs with express which is primarily a streams based system where you'd have to do extra work to write to disk.

It was never on the file system (kept in RAM) or it was in some temporary folder where files get deleted when an upload request has finished processing the file to prevent DOS attacks. Automatically keeping uploaded files sounds like a really really bad idea.

While I kind of agree with the sentiment, I'm also totally done with the notion of "Apple decides to have their own unique format every 2 years, and makes the change in a backwards incompatible way, so now the world needs to kowtow to them, despite Apple dragging their feet in many areas of standardization."

Seriously, fuck Apple. It took legal changes in the EU to force them to the "Just f'ing support USB-C like the rest of the world instead of making half your money selling dongles".


It's funny because the Lighting connector has been around since 2012, when Android phones were largely using Micro USB, with an awkward flirtation with the wide USB3 connector. Now they're standardizing on USB-C, so if you were upgrading frequently you may have needed 3 cables in the past 8 years.

Before then iPhones used the 30-pin connector, backwards compatible with 5-year-old iPod accessories. At that time other manufactures seemed to be shipping different barrel-plug chargers and proprietary cables for every model.

So that's 2 connectors introduced over a span of 18 years supported by dozens of product models that sold billions of units. Cables have been available from third parties for most of that time. The only dongles that might apply are 30-pin to Lightning or USB-A to USB-C.

The 30-pin's raison d'être was to provide features you couldn't get out of USB, like analog audio and video out. And Lightning was a much better designed connector than Micro USB due to being reversible, which informed the design of the Type C connector.

I'd agree that the Mac now has a dongle problem, but it's precisely _because_ it switched to USB-C, as you suggested.


This is misguided. The problem is not how quickly one format or the other iterates. The problem is forcing your users to endure a closed, licensed format.

A USB accessory will work on any device, but a lightning accessory only works on an iPhone, to nobody's benefit but Apple. Apple's hate of standards is anti-consumer, and that's why the EU ruled against them.

What particularly ircs me is that Apple has acknowledged that USB-C is the superior plug by going all in on their laptops. But they can't let go of all the money they make selling licenses for third party cables on iPhones.


> The problem is forcing your users to endure a closed, licensed format.

Lightning was a huge win for consumers because it was years ahead of the incompetently designed clusterfuck that micro-USB was.

> Apple's hate of standards is anti-consumer, and that's why the EU ruled against them.

Apple’s “hate of standards” is in part the reason the USB-C ecosystem exists today. They contributed quite a bit to its development.

The EU ruled against Apple because the EU is full of bureaucratic idiots that care more about looking good than actually knowing what they’re doing. The circlejerk that the EU is always correct needs to end.

If the EU ruling happened a few years ago we’d never have had Lightning and we’d have been stuck with the piece of shit known as micro-USB. Thankfully, Apple was allowed to innovate independently as any remotely reasonable government would allow, and created a connector that would later inspire USB-C.

> What particularly ircs me is that Apple has acknowledged that USB-C is the superior plug by going all in on their laptops. But they can't let go of all the money they make selling licenses for third party cables on iPhones.

Catch-22; if they change the cable people like you complain that they’re trying to obsolete accessories, and if they don’t change the cable people like you complain that they’re trying to profiteer off of accessories.


HEIC was developed by the Moving Picture Experts Group as an open standard.

Apple was early in supporting the standard. Windows, Android, others have followed. More to come.

When venting one's spleen, it's best to be at least a tiny bit correct.


>HEIC was developed by the Moving Picture Experts Group as an open standard.

It’s hard to call something an “open standard” if anyone who wishes to use it needs to license patents from nokia.

(https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F... under “licensing”)


And MPEG (through MPEG-LA) has long been known to be fairly active in litigating (or facilitating litigation) of the patents they administer.

> It’s hard to call something an “open standard” if anyone who wishes to use it needs to license patents from nokia.

If something needs a licence, it isn't open. I mean, it literally doesn't meet the definition of open.

What's more, if the standard was open, then that would be great, but adopting it so soon and setting it to be the default is woefully shortsighted.


I find it really surreal that this format is named "high efficiency image file format" when it makes no guarantees, no claims, and harbors no aspirations about efficiency. It's an encoding-agnostic container format!

You're correct, I shouldn't have said their own unique format.

Still, what matters is the reality of the situation. They could have easily made it so that uploading or transferring images, especially to websites, uses a standard format that 99.9% of websites support, instead of one that virtually noone supports (yet).

And at the same time that Apple rushes to support this new standard without providing a good backwards compatible experience, they've been dragging their feet for YEARS on Safari support for progressive web app features that would let devs build truly feature-comparable web apps without being beholden to the App Store walled garden.


> They could have easily made it so that uploading or transferring images, especially to websites, uses a standard format that 99.9% of websites support

They do.


The parent comment said they sent a tweet a week before, and they had something in their faq but it doesn't say how long before that was done.

Generally, when I've worked at places that were not startups a week to get something pushed in to fix something was not reliably enough time.

I didn't see in the article anything about how long they have been aware of the problem, perhaps they became aware of the problem just before the testing was scheduled to start. I guess that is a problem with their QA system, but at any rate I can think of lots of ways that they could have a problem for a week (or even longer really), not be able to fix it in their particular system, and have to notify people.

Of course I agree they did a lousy job of notifying people.


Yeah, I'm not surprised, since corporations like this are more concerned with making sure the Business Impact Assessment was routed in compliance with Standard Operating Procedures, establishing the Quality Verification Steering Committee to discuss possible impact to critical systems, and getting sign-offs from Validation Specialists and Risk Analysts.

Ask me how I know.


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.


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.

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.


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.)


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.


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

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.

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

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).

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.


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 they had enough time to warn people ahead of time, they had plenty of time to push a fix to their system for this

Yeah, no. Absolutely not. All of the testing for their platform would have to be redone, and if a bug is found, then what?

You can argue that they should have done a better job notifying users, but to argue that "of course they had time to push a fix in the week before the most important testing period" is just nonsensical.


ImageMagick supports HEIC to JPG conversion. It would take at most a few hours to hack together an interim solution.

IIRC, you have to use special flags when you compile from source to get HEIC support. And just because it's available doesn't mean you can legally use it. For example, the HEIF container's reference implementation is pretty explicit about not allowing commercial use [0]. The MPEG consortium lists over 7000 patents on their webpage for HEIC[1]. Making sure that you're bit infringing on those patents and/or working out a license deal with the patent cartel is a nontrivial amount of work.

[0]: https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

[1]: https://www.mpegla.com/wp-content/uploads/hevc-att1.pdf


I don't think you would be comfortable pushing this few-hours-hack to a system of such high importance. A mistake, be it stupid or complex, could break far more than the issue at hand does. And you would be at fault. Would you like to receive the response of all the students then? Would you really dare to risk this scenario?

That support depends on installing or building native libraries (mainly libheif I think) which is not trivial or may be that something developers can't do due to security reasons, also it's different for each platform.

The software is open source, but (legal) usage requires a patent license from MPEG-LA for the H.265 compression (HEIC is just single-frame HEVC).

I don't think it would have been possible to push a fix that quickly. Verification and sign off on these sorts of systems would require weeks or months to push changes.

> The iPhone is the best selling model in the United States.

To clarify: It has the best selling model, but it is not the most used mobile OS among US mobile phone users.


iOS's market share in the US is 61.25% according to [1].

[1] https://gs.statcounter.com/os-market-share/mobile/united-sta...


StatCounter shows the number of folks who visit sites with StatCounter on it.

Fun fact: iOS users generally do more browsing, so this has a tendency to skew stats like StatCounter.


Similarly NetMarketShare shows Android at over 70%, since they are more business website heavy. This stat is just as flawed as StatCounter's is.

What data are you basing this on?

Pretty much any mobile industry stat. Most have Android at a bit over 50% in the US and Apple at a bit under. Worldwide, Apple is under 20% market share. Remember, iOS is just Apple whereas Android is Samsung + LG + HTC + Google + Oppo + OnePlus + etc...

Examples:

https://www.counterpointresearch.com/us-market-smartphone-sh...

https://www.statista.com/statistics/266572/market-share-held...


Have to agree with this guy here.. if you are doing Q/A testing and you notice that an iphone doesn't work by default, you have a problem.

Perhaps it's the iPhone that's broken then.

HEIC isn't exactly a commonly used, or widely accepted image format outside of Apple's world.


Just a guess, but it seems like you work in theoretical lala land and never have to deliver something that works.

I'm not saying you are wrong- sure you can argue that it's the iPhone that is broken, from a non-standard format. However, if you are designing an app that needs pictures to be taken and about 45% of your customers (the students) can't just take a picture without going through some conversion while on a time sensitive test- then you majorly fucked up.

End of the day this is on the AP designers for not adding a format which 45% of their base will use by default.


Scanners almost universally output in TIFF, and need to be converted to JPG or something more universally accepted. Nobody complains.

Some scanners even will do the conversion to JPG for you, because they know nobody accepts TIFF files.

If Apple does it, then everyone has to accept it?

And why? Because images are large and Apple's trying to reduce the size on the phone? How about giving everyone more than 5GB of iCloud storage in 2020? Google gives you 10-15GB for free, and costs half as much for more storage.

For premium-priced devices, this is absurd.


Well I could turn that around and say if you develop a phone and the image format it exports to is not accepted by 99% of websites maybe then you majorly fucked up.

But the phone does the right thing when told to do the right thing. If the input tag has a proper accepts attribute set the iPhone will transparently and automatically transcode a HEIC image to JPEG.

A file input tag with no accepts attribute when you're expecting a particular type of file is broken. Would Android phones be "majorly fucked up" if they stored images as WebP by default?


The question is, is it the exam developers task to produce software that works in the world as it is or the world as they would like it to be?

If the latter this is a roaring success.


People used to say the same thing about Internet Explorer

And they were correct. If more than 10% of the population is using it, it should be supported, particularly if you are providing a service that can affect people heavily (like AP test submission).

What's your point?

If you are developing an application/website and it doesn't work with 50% of your market share- then you are a dumbass for not implementing it.

ESPECIALLY for an AP EXAM with consequences.

This isn't like "oh no, 50% can't reach our site about cat videos". This is an EXAM.

Honestly cannot believe people on here defending them not adding simple image support for 50% of the testers...


HEIC isn't simple, and isn't common.

Apple should convert to JPG or PNG when exporting the image to anywhere anytime.

The same problem happens with webp images too - totally unusable almost everywhere, even in photoshop.

Apple wants to reduce storage space photos take up. Fine - but they should convert back to a standard format when exporting the image to be used on some other system.

With that said, it seems the issue is from students that didn't upload the image from their phone (where Apple correctly converts to JPG), but rather transferred the image to their computer, then uploaded into the AP Exam.

If that's true, then this is absolutely on Apple. Why would they export in a format that literally nobody else supports. What are these people supposed to do with a folder full of HEIC formatted photos, that can't be uploaded anywhere else, edited with any program, or opened even opened on some Operating Systems?

Apple should assume nobody else uses HEIC because... well, nobody else uses HEIC.


Nothing starts common, you have to start somewhere, and it is an ISO standard format.

A file format, used by one company, isn't going to change the world.

JPG and PNG are here to stay. Love it or hate it... they are the lowest common denominator for image formats.


File formats change fast. It was not too long ago PNG was the newcomer, and people were touting how much better it was than GIF for non-photographs (alpha transparency, better compression, etc.). It has been successful, and now almost all applications support it. Same thing with moving from AVI to the MPEG formats in video.

New formats are a good thing, and fast adoption of them is good for users.


>used by one company

Samsung have started changing over as well, it's the default on their latest phones.


> it is an ISO standard format.

So is COBOL[0]; that doesn't mean you should ever use or support it.

0: https://www.iso.org/standard/28805.html


The point is that we have all seen what happens when we start letting a single company dictate formats. Because the next step is "i can't believe those lazy fucking programmers can't support heic2" or whatever magical bullshit they come up with after abandoning heic1.

And it you want to talk about incompetence, I'd say pushing a format that is almost guaranteed to be incompatible with the millions of existing backends out there is profoundly stupid.


>...a single company dictate formats.

It's an ISO standard. Samsung phones use it as well.


Oh yes, let’s update our tested and working system, a week before live? Don’t be stupid.

There were probably no dev changes for the entire month before hand.


> If they had enough time to warn people ahead of time, they had plenty of time to push a fix to their system for this

At the very least, a message that appeared at the time that one attempted to upload the image with instructions on how to fix the problem on the spot. How hard could that have possibly been?


Quite hard? I mean shame on them for letting this bug through in the first place but I'd be pretty horrified if someone at CB tried to hot-fix this problem out.

This isn't a small agile organization, it's enormous and may not have any route to get a patch out in less than a week due to QA requirements. (That isn't to say such slow deployment processes are good, but they do exist and may be contractually required)


Who said anything about a hot fix? They knew about the problem well ahead of time.

Anything less than 2 fiscal quarters is a hot fix for these people.

> adding support for one more image format

I seem to remember that HEIC is quite patent-encumbered. Could this possibly cost them a lot or be more complicated than you seem to imply?


> The iPhone is the best selling model in the United States.

That's an interesting (and slightly misleading) way to present that statistic. Apple has the best selling models, but does not have the majority of the market by operating system, which is what matters here. It's close, but Android is still supposed to have over 51% of the US market.[1] (If the graph itself is occluded, see the summary below it).

> It is on College Board to support its default image format.

It's a minority platform. It's only a slight minority, but it is one. If you want to make a case that they should support any default format for a platform over a certain percentage of usage (or "almost half"), that's fine, but you can't rely on the obvious argument that it's the dominant platform and thus should be supported, because it isn't the dominant platform.

Edit: Whoops, forgot to include citation

1: https://www.statista.com/statistics/266572/market-share-held...


I disagree. Bowing down to the whims and fancies of corporations is how we got into this situation (in terms of media formats) in the first place. According to wikipedia, HEIC isn't even supported in any browser natively, clearly rolling it out this soon was a bad idea.

Media format support will always be a chicken and egg problem. You got to start somewhere.

Apple's approach of automatically converting images at the edges is the right way to go. It does require your software to be explicit about what media formats it understands. This is where the College Board failed.


>Media format support will always be a chicken and egg problem. You got to start somewhere.

Funny thing to say in support of Apple. Maybe they should support WEBPs/WEBMs instead?


Their approach to supporting the new formats is actually quite easy to work with and properly defined input tags will just automagically trigger file conversions on the iOS side.

I also really dislike Apple's usual "my way or the highway approach" (it's causing my nephews serious issues since some of their remote learning tools use flash which Apple refuses to support) but in this case they are using the right approach to make it a smooth transition.


> it's causing my nephews serious issues since some of their remote learning tools use flash which Apple refuses to support

That's really not Apple's problem. Flash Player is dead. Adobe has declared that all support for the plugin will end in December 2020, and every major web browser has indicated that they intend to discontinue support for the plugin in advance of that date. Some desktop browsers (including Chrome and Firefox) have already disabled Flash content by default, and the Flash plugin for Android was discontinued in 2012.


As a developer I'm totally onboard with Flash having died a while back - and these tools educational suites really shouldn't have anything to do with Flash... All that said, when Apple killed Flash they did it unilaterally and really did break a lot of existing systems, if this pandemic was happening a decade ago I'd absolutely be on an Apple hate train since the sudden drop of support forced people to scramble.

At this point though, Flash is known to be dead and buried and folks that haven't migrated off of it have made their own beds[1].

1. ...And unfortunately caused a lot of headache for quite a few parents with multiple children that are trying to let all their children learn concurrently on different devices they have around the house.


> when Apple killed Flash they did it unilaterally and really did break a lot of existing systems

What are you referring to when you say "when Apple killed Flash"?

The big outcry was back when Apple made it clear that they would never add Flash support to iOS. But that support never existed in the first place -- one can hardly "kill" something which was never alive.

Desktop Safari still supports Flash, for now. It's off by default (with a "click to enable" icon), but that's no different from how it's handled in other browsers. All signs indicate that they intend to remove Flash support with the next major release, but that just puts them on the same track as everyone else.


Refusing to support the tech on your platform is killing it. iOS's big selling point, initially, was as a consumption device - a phone with a browser. Deploying your browser without flash was removing some expected support from the norm expected of a browser at that time.

And yea - I agree that flash is dead at this point and I'm quite happy it's gone. Apple actually contributed significantly to the death of flash based advertisements and there is nothing in the world I hated more than those.


Open competition among standards is the way adoption has mostly happened at least since the VHS/Betamax days. Otherwise it’s decision by committee and/or fiat which can sometimes be a net benefit but more often than not standardizes on a cumbersome standard that is not a good fit for any one application.

> letting students take the test again.

Yeah, that still fits "our system broke, you're screwed now, sorry".

They have the submissions, the submissions can be easily converted to their target format. That's what they should do instead of asking students to take the test again.

Or maybe they simply delete any accepted[1] submission that they deem corrupted, in which case I have nothing more to say.

[1] Quote:

> Spencer used the same process on the real exam and thought it went through, but he received an email the next day saying the files were corrupted and that he needed to retake the test.


Spencer's file might be on the server but it sounds like their servers flat out refused to accept any files that looked like HEICs - so they never even got them on the server.

That's a stupid decision, especially when the submission window is timed - fiddling with file formats should never be a task you need to do inside of the testing window.


These tests take a not insignificant amount of time and stress to do, especially on top of this SiP situation. Not to mention they cost the students money.

Communicating these issues only over twitter is also not at all acceptable. Plenty of people don't use or rarely use twitter, such that it should not be considered the primary communication channel.

So while yes, College Board is allowing students to retake the tests, anyone affected should be refunded at least partially, if not fully, for having their time wasted. College Board should have had their backend reject invalid formats, not just hang. The result of attempting to upload an invalid format image should have been a 'whoops, please use a different format', but that's not what happened.


This isn't just the College Board. You wouldn't believe how many schools and educators out there now just assume you have a Twitter and Facebook feed and check it regularly. Email and phone calls are completely out of the picture now.

> letting the students take the test again

Maybe you're not aware of how much time, energy, stress, etc go into taking these tests.

Imagine if your university lost its records of your undergraduate degree and offered to fix the problem by letting you earn your 4 year degree over again. I think you'd agree that wasn't an acceptable solution.

This situation is not that order of magnitude, but it's similar perhaps to taking an entire college course. My wife works with high school kids and they are losing their minds over this, and I think they are justified.


> The website got stuck on the loading screen until Bryner’s time ran out.

If I am to write a system that accepts user uploads, verifying the uploaded file and giving proper error message on failure would've been the first thing come to mind. In this case, per the article, the system was stuck. This is simply unacceptable.


> even sent out a tweet (which should have been an email) a week before

This problem seems like it could easily have been fixed in under a week.


Is it really so tough to shove an HEIC-to-JPEG converter in their pipeline?

Seriously, it's not. It's an attribute setting on the file input field. The iPhone will do the conversion itself, it just needs to actually be told what to convert to, rather than having to guess.

The FAQ and tweet are clearly the wrong way to communicate such vital information. Neither are required instructions for students. The FAQ is explicitly labeled as being for educators, not students. Neither explains the consequences of doing it wrong and make it sound like something minor such as having to choose a different option if it doesn't work. If I was serious about something like an exam, I'd read all the actual rules and ignore the "important tips" for a "smooth experience" or other crap that's always excessive and usually useless anyway.

It sounds like either they actually didn't know it would crash so badly or they were too embarrassed to admit having such a serious bug but wanted to quietly steer people away from encountering it without them knowing they dodged a bullet. If the latter, then the College Board was acting maliciously to protect their reputation which is really bad.


Even without that, they mentioned in their FAQ that JPEGs and PNGs are the only file types acceptable

That's like telling people what brand of pencil they are allowed to use to mark paper. It's not germane to the test and improperly shifts the burden to the student when the technology to automatically screen already exists.


It might be like saying the students are only allowed to mark their answers in blue ink or black and no other colour rather than saying it's a particular brand.

Everyone can look at a pen stroke and identify the color.

Can you say the same about a photo and identifying the file format?


I'd imagine it's worse now, but I was sweating blood during my AP tests 8 and 9 years ago.

If I were told by College Board that they messed up, they couldn't verify what I did, and that I'd have to take the tests again, I'd be livid. I would feel incredibly screwed.

On top of a pandemic, new test guidelines, classes going remote (and the associated growing pains), studying for the test, and some extra stress-studying because some classes inevitably were taught ineffectively at the start of remote courses, now some people have to take the test all over again? That's a lot for a most people but especially high schoolers


Taking the test again is a horrible solution. How is that ok?

Yeah, what a weird "solution" to be okay with. Wonder if they'd be as okay with repeating a workday because their hours weren't logged due to a system error.

The college board is a pretty badly managed technology and testing monopoly (duopoly). e.g. retrieval of scores in past years for the SAT was gated by region, but if you got on a VPN you could get your scores from unreleased regions. I had a niece provide their credentials to a sketchy website that in the end delivered scores "early", but there was a talk about online security afterwards with the parents and the neice.

I do have some mixed sympathy for having to set up a whole new online testing scheme for the tests due to Covid, but their approach was so odd. Students were also instructed to compose text answers outside the test pages, and copy and paste them into answer boxes. An odd & ugly solution, but it points to at least some thought about trying to mitigate unreliabilities.


Far too many technology decisions and implementations in post-secondaries are made by academic/bureaucrats who have no expertise or background in technology.

It's honestly one of the biggest conundrums facing academia.

Year by year, incoming students generally have a higher base level of digital literacy than their instructors, because academic institutions did not prioritize developing those skills 10-20 years ago and the proof is showing in the pandemic pudding.


I don't know what academic institutions you're talking about (it means university in my book), but in non of the academic institutions I worked for did the academics have anything to do with IT decision making (except for maybe filling out a survey). Which is unfortunate because then we wouldn't have to deal with stupid IT people coming from large businesses and thinking that universities are just the same as any business. To give you examples of some of the stupidity I have seen from university IT (and yes they are almost completely recruited from other large businesses): operating system researchers not given admin rights, every semester break reimaging the lab pc and never checking that the special drivers and software for the lab equipment is installed correctly (solution: have the professors/academics check every lab PC before semester starts, great thing to check 200 PCs one week before the beginning of the lectures where you have lots of other things to do), no ability to share calendars with outside people because security (suggested workaround just sync to Google on you phone and use that, I kidd you not). Generally, only buy Microsoft (or some other huge proprietary vendor) tech which can never be adjusted to the needs of the academics actually working with it.

TLDR there is lots of things wrong with It in academia, but academics making the decisions is not one of them. Also, generally most universities I know about were reasonably well prepared for online courses and it worked largely seemlessly.


> Far too many technology decisions and implementations in post-secondaries are made by academic/bureaucrats who have no expertise or background in technology.

Many people who are very knowledgable in technology (the SV bubble is rather an exception) are very conservative in terms of it. Don't confuse good programmers with "technology hipsters".


I'm not talking about programmers at all - rather the technology strategy and policy designers and implementers that come before them.

My background includes software dev in and around online education for almost 20y in both industry and academic.

Totally outside bubbles and following groupthink :)

The conservatism from technologists that you speak of.. in part comes from the politics at post secondaries and the resistance towards adopting technology.

There's no shortage of understanding in most institutions of the problems and how to solve them, only the political will, and leadership who cares.


> ... We'll just take it on trust that you do so honestly because there's no way you would've seen this coming. ...

I see where you're going here, and I want to agree, but you aren't reckoning with the incentives for cheating on the AP.

My kid is taking the "AP World" test today. One of her classmates was asked to sit by a different student to coach them at their computer during the test, because the test is done remotely this year rather than in person.

I'm afraid that if you give N people an option like this, a fraction will exploit it.


They would have a server log of who tried on time to submit it and had server errors. Those people could not have foreseen this... so we can accept their late submissions

The articles seems to indicate that the upload crashed, so they probably don't have the files

Which is why GP proposed giving students the opportunity to email the files separately.

This is college board we are talking about. I guess parents will just have to pay for another exam and hope its graded fairly.

One might also ask why in 2020 your taking an exam and then photographing it.

Some of those with problems actually had real computers as well.


it may be way write physics, math calculation with pen and paper than trying to type that in the computer.

The example given was an English paper

To be realistic, that is an acceptable answer if the person being screwed lacks alternatives and negotiating power.

You mean "I don't want 'you"re screwed, sorry' to be an acceptable answer" and I get that, but I'm committed to using honest language about this because thats we you train ourselves to be wary and give these situations the respect they deserve.


No, it's not acceptable. They might be able to get away with it, but that doesn't make it okay.

I thought iOS was supposed to convert HEIC images to JPEG automatically behind-the-scenes in any file transfer situation where HEIC isn't supported. The article itself even says:

> iPhones convert HEICs to JPEGs automatically when they’re attached to emails in the Mail app

I'm just curious technically why the same didn't happen with the testing portal? If you have a webpage that accepts image uploads, is iOS Safari not smart enough to do the same conversion?

Or was the portal programmed badly or in a non-standard way that that couldn't happen? Or is there a way to do it that the developers ignored?

Just curious for the technical details of who's more to blame here -- Apple not providing enough backwards compatibility, or the testing portal being designed poorly.

Because blaming students for not following obscure instructions to change their phone's overall configuration is not the right path. A national testing portal ought to support the default image format taken by the world's most popular phone, period.


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.

Ten bucks says College Board programmer(s) failed to do the most basic and standard filtering.

Edit: Like a sibling comment said, the accept attribute actually isn't necessary; even PNG images (e.g. screenshots) from Photos are converted to JPEG automatically. This is true on both macOS and iOS Safari (latest). To be clear, on macOS you need to select from Photos instead of the filesystem for this to take effect.

In case anyone's interested, source code you can use to test for yourself (a Flask app):

app.py:

  import flask
  
  
  app = flask.Flask(__name__)
  
  
  @app.route("/", methods=["GET", "POST"])
  def index():
      if flask.request.method == "POST":
          image = flask.request.files["image"]
          return f"uploaded {image.filename!r} ({image.mimetype})"
      return flask.render_template("index.html")
templates/index.html:

  <html>
    <head>
      <meta charset="utf-8" />
      <meta name="viewport" content="width=device-width, initial-scale=1" />
    </head>
    <body>
      <form method="post" enctype="multipart/form-data">
        <input name="image" type="file" required />
        <input type="submit" />
      </form>
    </body>
  </html>

Turns out I overlooked some details in the article. Some students (after the issue was known) airdropped photos to their computers and attempted to rename .heic to .png/.jpeg to bypass the extension check (who would have guessed extensions don't have to correspond to file types), they went through but were rejected a day later. The article isn't clear on what exactly was happening before, but I suppose students were trying to submit airdropped .heic directly?

In any case, sounds like absolutely horrid QA and communications of what's accepted (and of course, very bad idea not supporting the format in the first place when half your test takers are taking pictures in that format).

(A bit more context on my original comment: I thought they had some working system where test takers could upload photos directly from their phones — e.g., scan a QR code to open a page with a unique ID with an image upload form. Turns out that's too much to ask; their process is "get the image from your camera to your test-taking device whichever way you can think of, not our problem." Not surprisingly that's not a very foolproof process.)


If they were submitted in time, but then rejected a day later, it seems like those cases can be resolved by some manual work by collegeboard to convert them

"Be strict in what you send; be liberal in what you accept" seems a relevant maxim here, but I wonder if it's reasonable to assume given the utter ubiquity of PNG and JPEG that of course that's what other people would be using?

If you're going to make an assumption, that one is definitely understandable.

However, taking a step back, you should have enough representative test cases (QA snaps a photo with iPhones, tries to upload) that whether assumptions are reasonable doesn't enter into it because you aren't making them.


Sure, and turns out you don't even need the accept attribute (see edit). They're doing something funny.

> Ten bucks says College Board programmer(s) failed to do the most basic and standard filtering.

Why is it a failure of the college board to put "accept="image/jpeg"", instead of iOS which failed to default to the more standardized jpeg format when HEIC was not specified?

HEIC is a newer format which fewer systems support. iOS / Safari should default to JPEG in this case.


Because a lack of an accept attribute on the file-input element has a defined meaning in HTML, and that meaning is accept="⋆/⋆".

Which, in turn, means that the form isn't putting any constraint on what's being uploaded at all, and so there's no reason to think that the form is asking for an image in the first place. At that point, it's asking for a file. Any file. And so it has the semantics of taking whatever file you provide it as-is, with no transformation necessary. Just like when a client requests `Cache-Control: no-transform` from a server. It wants the thing on the other side sent to it as-is.

And, it's important to support those semantics (and that particular implicit meaning for leaving out the `accept` attribute), because such "as-is" uploads have many use-cases. The form might be e.g. a computer-forensics or antivirus-signature portal, that wants an evidence file; or the interface to a hex editor or decompiler, that expects a raw binary with arbitrary extension in unknown format; or the SCP component of an old web SSH terminal emulator. All these existed on the web, and used <input type="form">, before the `accept` attribute was introduced. So "not using the `accept` attribute" has to retain semantics that are backward-compatible with that legacy.


Generally I agree with your point but this isn't your uncle's homemade public photo gallery. These are people's lives on the line. These kids have no say in whether they think they should take these exams. And because of that yes it is absolutely College Board's responsibility to

1. Correctly label their expected stream types. 2. Test all of the most popular devices before having something this broken in production.

What about a kid that's using a cheap android tablet from aliexpress? Are you arguing that the company nobody's ever heard of is at fault for not programming their tablet to use the correct image format? I agree that they should probably be using JPEG but that doesn't mean College Board is off the hook for making it easy for a user to not be able to use their product for something this important.


Not being able to accept common image formats is a failure of the programmers, not Apple, which is looking to use more modern image formats that have better compression and quality.

It really bothers me when programmers make excuses for laziness or shoddy work that results in user's being harmed. Start caring about your users.

The iPhone is the most popular phone model in the United States. This is on the College Board. It takes very little work to make this work properly, which ANY BASIC QA PROCESS WOULD HAVE CAUGHT.


Check the actual source code: https://news.ycombinator.com/item?id=23261598

I don't think the failure is with the accept type. I think the failure is with the bespoke JavaScript checking the filenames. That puts the failure on the College Board, not Apple.


The comment was edited to show that iOS does in fact do this.

But even if it did send HEIC, if you're going to fail to handle "any" format, then you better specify the one you can handle. By the same token, why shouldn't my computer convert every .docx to PDF, or some other "more universal" format?

Instead of specifying the requirement programmatically, they spent their time sending out tweets and writing help docs.


> Instead of specifying the requirement programmatically, they spent their time sending out tweets and writing help docs.

Point of order: separate people, with separate/independent/concurrent job responsibilities. It very likely wasn't the programmers tweeting and writing docs. (Heck, I expect that the College Board doesn't even retain any full-time programmers, only contracts with firms for projects.)


Separate people, yes, and we should not blame the people sending out the tweets. But we can hold the organziation they belong to responsible.

It's the same as if Apple shipped me an empty box instead of my iPad Pro. Of course I can't blame the customer support person who takes my call, and I shouldn't be rude to them. But I would still blame Apple the corporation for such a thing, had it happened.


When was the accept attribute added to the input tag?

I was surprised by this, but at least as early as September 2008: https://github.com/whatwg/html/commit/c67bb312ac44737c6c175b...

1. input type=file can be used to upload any file format (or any non-format, for that matter). If you want specific file formats, you make your intention clear.

2. Please try to read the entire comment. iOS does default to JPEG when uploading, the accept attribute isn't needed.


When you are accepting photos that will be taken from a phone, why wouldn’t you test to make sure that your site worked with the default settings for a large (if not largest) proportion of your users? If you are the College Board, it seems irresponsible to not have tested this better. Or at least saved the data to attempt to convert later (which it doesn’t seem like they did either).

And if they really needed to control the file formats this much, they should have written this functionality into an app (for iOS and Android) and handled taking the picture themselves.

They really screwed things up for a bunch of kids here.


Imagine trying to upload a heic file to (say) Amazon s3 through their web UI and having it converted to JPEG.

If I wanted to upload raw photos from my camera to a generic file storage site and they all got magically converted to jpeg because the browser thought that was the best image format, I’d be pretty pissed off. Browsers should follow standards.

Wow, I didn't know browsers even supported automatic image format conversion (this is pretty impressive IMO). Terrible that their programmers didn't specify that tag attribute.

I don't believe that's what's happening here. The accept attribute just filters what files show up in the file picker. And iOS devices will take an extra step, and on the operating system side convert HEIC files to JPEG.

Thanks for that explanation, I was wondering how it worked.

Is this the case on both Desktop and Mobile Safari?

Yes, see edit.

Would it be correct for iOS Safari to quietly reencode to jpeg when a HEIC file is uploaded via a webform? How would Safari know that the site's backend didn't want an HEIC file?

I agree the HEIC thing is very confusing (having set up my parents' phones recently), but I can't see how Apple is to blame. For starters, the College Board could've done a much better job emphasizing this step for iOS users in its instructions page. But for me, the overriding factor that places blame squarely on the College Board is this from the article:

> Senior Dave Spencer took a demo test before his Calculus AB exam to make sure he understood the process for uploading photos. He Airdropped an iPhone image of his responses to his Mac and tried to convert it by renaming the HEIC file to PNG. Changing a file’s extension does not guarantee that it will be converted, but Spencer was still able to submit the demo test with no problem.

> Spencer used the same process on the real exam and thought it went through, but he received an email the next day saying the files were corrupted and that he needed to retake the test.

So it seems that students had access to a demo before test day. If I'm reading the story right:

- During the demo, Dave's phone produced a HEIC file

- The demo upload initially failed. So Dave renamed the file extension to PNG.

- Dave uploaded the PNG (in name only), and the demo did not return an error.

- Dave assumed, quite understandably, that the renaming trick would work on test day too.

So the onus in the College Board here: they provided a demo in which the photo upload function appears to have been stubbed (e.g. "if 'PNG|JPG|JPEG' is filename, print "Success"), giving students and teachers false assurance that photo uploads would work on test day.


> they provided a demo in which the photo upload function appears to have been stubbed (e.g. "if 'PNG|JPG|JPEG' is filename, print "Success"), giving students and teachers false assurance that photo uploads would work on test day.

I don't think it was exactly that it was stubbed out, per se; I would guess it was that the whole "backend" process involved either a human or an async batch process opening the file; and so in both the demo and prod environments, the upload of a file can succeed while the parsing of said file can fail (much later on, after the test is completed, during the grading phase.)


Yeah, I agree with you that the production app likely had an async process, i.e. queuing submissions and processing them first-come-first-serve, which would help explain why Dave didn't get the failure email until well into the next day. Seems safe to assume there was no process for (good) input validation upon upload.

And now that I reread the passage about Dave, I realize it's not necessarily true that Dave tried to upload HEIC, then got an error message, which led him to then rename the file. But he may have actually read the instructions about PNG/JPG being required, then thought he could just rename his file, then uploaded it as his first and only upload to the demo app. And whether the demo app actually did the upload, it apparently didn't do the parsing (I still think that was stubbed out; I can imagine an engineer thinking it'd save a headache if they disabled the parsing module for the demo server)


Yes there was a demo, but it didn't actually submit anything at all. It just mocked through what the exam would look like with timers.

The demo is still up and you can still look at it


So they did have a dress rehearsal, it just wasn't high fidelity, and on perhaps the most critical part of the process.

Does the HTTP "accept" tag play a role here?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...


That's a header the client sends to a server to indicate which formats it would like in the response to it's requests, and not relevant to the problem.

I don't follow. How does the "Accept" header factor in here?

Rule of least astonishment would be that the file is converted unless the accept header lists the heif file. At least by the expectations Apple set up, which don’t match up with standards.

> If you have a webpage that accepts image uploads, is iOS Safari not smart enough to do the same conversion?

AIUI, Mobile Safari always re-encodes the image. However, if you transfer the image to a device that supports HEIC (e.g., recent macOS) then you'll find out that (desktop) Safari never re-encodes an image when uploading a file.


> (desktop) Safari never re-encodes an image when uploading a file.

Not really: https://news.ycombinator.com/item?id=23261216

Images are converted if you select from Photos (instead of the filesystem).


FWIW, as is the norm, my experience is that it works brilliantly --as long as you stay within apple defaults.

As soon as I stray from golden path - text using anything but Apple MEssages, email using anything but apple mail, post using anything but safari, use/process with anything but Apple Photos - HEIC has been an absolute positive pain in my keister ;-(

Other people may have more luck; note that my work iPhone is an isolated island - my other devices are either Android, or Windows/Linux - which probably explains my troubles to a large degree. Apple's selling point has always been the well-integrated ecosystem so I understand I'm an outlier.


Which is why IOS should default to sending JPG or PNG to/between any non-bespoke Apple product until such a time that HEIC is universally common. That should be transparent to both the end-user as well as the receiving end.

One can moan about the test site not being more robust/careful but it is Apple/Samsung that are using the new, non-standard format and expecting others to accomodate in short order.


The article reads to me like the people who had problems sent the images from the phone to their computer, which may not trigger the automatic conversion? One air dropped it to the computer and renamed it PNG, another renamed it JPEG, but they were probably HEIC files with the wrong file extension.

I believe those students had received noticed to use png/jpeg, and their solution was to change the file extensions. The website accepted them without issue, but these students later received emails telling that their photo was corrupt. The other, unaware students tried to upload the HEIC directly from their phones and the website stopped responding causing their test time to expire.

Ah gotcha, I think you're right. Sheesh.

Historically, Safari always converted to JPEG and I don't think that required something like setting the accept attribute (e.g. <input type="file" accept="image/jpeg">). It's not clear whether they're using something like the JavaScript blob APIs to get the file contents without some implicit conversion.

Probably not. If I Airdrop photos taken on my phone to my Macbook they arrive in HEIC format. I have to use an external tool (iMazing HEIC Converter) to manually convert them for a bunch of places.

I've experienced that with AirDrop too, but that's because the iPhone knows the Mac can view them.

Also you don't need an external tool -- Preview will convert HEIC to JPEG for you relatively instantly, even in batch. (Though I really do wish the phone would ask first if you want to convert, when Airdropping.)


I'll try Preview next time instead, thanks! iMazing works fine for the actual functionality but has some sort of bug where it won't re-open if I closed it without force quitting it. Minor but annoying.

That's likely an issue with iMazing not properly handling apple's saved ui state mechanism. You could try checking if holding the option key reveals a "quit and close all windows" option in the app's eponymous menu item, or press and hold the Shift key while opening the app to forget previous UI state.

If you don't care for apps to remember their previous windows and ui state, you can disable this mechanism in the settings app: https://support.apple.com/en-ca/HT204005#appresume


Wow, I have been using iOS (and keeping it up to date) and macOS and Photos.app and uploading images to sites regularly for quite some time and this is the first time I’ve ever even heard of HEIC. Whatever they are doing has been beyond seamless for me.

snazz posted the actual code downthread: https://news.ycombinator.com/item?id=23261598

My guess is that the JavaScript manually checking the filename's extension is screwing up the automatic conversion.


> A national testing portal ought to support the default image format taken by the world's most popular phone, period.

What if it can't because the format is proprietary and Apple wants to charge for its use? As I understand it, MS and Google have to pay licensing fees to enable support for it in Windows 10 and Android.


You're thinking of HEVC (video encoding, like h.265): https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

HEIC (image encoding) is available without royalties: https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For...

Regardless, in this case, as others noted, iOS would have just converted to jpg if College Board was using a standard image upload form.


>HEIC (image encoding) is available without royalties

As stated by that Wikipedia article, HEIF is the royalty-free container. HEIC means the content is encoded with HEVC, which makes it not free.


> HEIC (image encoding) is available without royalties

Ah, ok, thanks!


> When containing images and image sequences encoded in a particular format (e.g. HEVC or AVC) its use becomes subject to the licensing of patents on the coding format.

I'm not sure what you're trying to say with that quote? As I mentioned, HEVC is subject to licensing costs. If you try to wrap your HEVC video content in an HEIC container, you don't suddenly get to skip paying the original licensing costs.

He's trying to remark the fact that HEIC = HEIF(HEVC) => non-free. See my other reply to your first comment. Note that HEVC doesn't necessarily mean video. It can be used to compress still images, as it's the case of Apple devices.

Support it by performing client-side conversion to JPEG. The device obviously already has the license.

Have you seen what the College Board charges for AP testing? I think it's a cost of doing business and they can afford to pay a reasonable licensing fee to process the test results. If they can't, increase the test cost by another $5.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: