Michael B. Klein

I started looking into this issue because I was experiencing the same thing @konarskis was. It turns out it's not the `head_object` check that's taking so long – it's the...

I guess a less invasive version of that would be to create a dict that maps each function's resource ID to a hash of their `CodeUri` + `Runtime` and use...

I started working on the idea I posted about two comments up and never got anywhere with it. (I can't remember now if it was a technical issue or just...

`SAM_CLI_BETA_BUILD_PERFORMANCE` has been great. I'd love to see the `PACKAGE_PERFORMANCE` feature as well, since checking the same already-uploaded resource a bunch of times is currently the longest part of my...

Looking more closely at the working vs. nonworking JP2 files, it seems the one that does not exhibit the bad behavior only has one tile-part per tile. The issue still...

Re-creating the “working” JP2 with multiple tile parts causes the error again, so it seems to be happening whenever there is more than one tile-part per tile.

More data: I decided to see if the index order mattered, and found that while I could not read the tiles from `0..n`, I _could_ read them in reverse order...

I've created several more images with different numbers of tiles and different numbers of parts per tile. Unfortunately, the workaround mentioned above doesn't work for most of them. It does...

Yes, `opj_decompress` handles the image just fine, using the same version of openjpeg that libvips was compiled with (v2.5.2). It works with the whole image, as well as with specific...

And yes, I think @kleisauke may be right that this is a duplicate of #2621. `jpylyzer` shows some comment data from inside the file indicating that the image was compressed...