Most active commenters

    ←back to thread

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

    (www.theverge.com)
    669 points danso | 14 comments | 20 May 20 19:36 UTC | HN request time: 1.225s | source | bottom
    Show context
    crazygringo ◴[21 May 20 16:55 UTC] No.23260987[source]▶
    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.

    replies(10): >>23261070 #>>23261216 #>>23261225 #>>23261243 #>>23261256 #>>23261511 #>>23261741 #>>23262179 #>>23262549 #>>23264304 #
    oefrha ◴[21 May 20 17:08 UTC] No.23261216[source]▶
    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>
    replies(5): >>23261508 #>>23261519 #>>23261524 #>>23262200 #>>23262967 #
    1. dragontamer ◴[21 May 20 18:00 UTC] No.23262200[source]▶
    > 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.

    replies(9): >>23262291 #>>23262309 #>>23262430 #>>23262568 #>>23262681 #>>23263513 #>>23264517 #>>23266964 #>>23268483 #
    2. bjtitus ◴[21 May 20 18:04 UTC] No.23262291[source]▶
    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.

    replies(2): >>23262490 #>>23264563 #
    3. oefrha ◴[21 May 20 18:05 UTC] No.23262309[source]▶
    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.

    4. salamander014 ◴[21 May 20 18:11 UTC] No.23262430[source]▶
    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.

    5. nitrogen ◴[21 May 20 18:14 UTC] No.23262490[source]▶
    When was the accept attribute added to the input tag?
    replies(1): >>23262807 #
    6. pwthornton ◴[21 May 20 18:19 UTC] No.23262568[source]▶
    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.

    7. scott_s ◴[21 May 20 18:26 UTC] No.23262681[source]▶
    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.

    8. bchociej ◴[21 May 20 18:32 UTC] No.23262807{3}[source]▶
    I was surprised by this, but at least as early as September 2008: https://github.com/whatwg/html/commit/c67bb312ac44737c6c175b...
    9. mbreese ◴[21 May 20 19:14 UTC] No.23263513[source]▶
    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.

    10. derefr ◴[21 May 20 20:18 UTC] No.23264517[source]▶
    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.

    11. derefr ◴[21 May 20 20:21 UTC] No.23264563[source]▶
    > 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.)

    replies(1): >>23267626 #
    12. mr_toad ◴[21 May 20 23:40 UTC] No.23266964[source]▶
    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.
    13. braythwayt ◴[22 May 20 01:03 UTC] No.23267626{3}[source]▶
    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.

    14. zodiac ◴[22 May 20 03:52 UTC] No.23268483[source]▶
    Imagine trying to upload a heic file to (say) Amazon s3 through their web UI and having it converted to JPEG.