toFormat webp returns InvalidImageFormatException

[theopape]

Describe the bug
We're getting an error with webp. If we try to use toFormat: webp we get:

{"status":400,"code":"InvalidImageFormatException","message":"Request has invalid image format"}

To Reproduce
set toFormat to webp.

Expected behavior
toFormat should accept webp. This should be independent of auto webp being enabled or not.
Please complete the following information about the solution:

• Version: v6.0.0
• Region: eu-west-2
• Was the solution modified from the version published on this repository? No.

Screenshots

Additional context
We need to do this in order to successfully send images to smartCrop, so can't use the auto webp, this is to do with lambda payload size limits.

[fisenkodv]

@theopape thank you for reporting the issue. Can you share the image (if not confidential/sensitive) that you are having issue with? It will be helpful for us to look into it then. Do you see any errors in the CloudWatch?

[theopape]

https://images.dronework.io/eyJidWNrZXQiOiJkcm9uZXdvcmstaW1hZ2VzIiwia2V5Ijoid3AtY29udGVudC91cGxvYWRzLzIwMjIvMDYvMjAxNDAzMTkvRkNQWC1EUk9ORS1FRElULTEucG5nIiwiZWRpdHMiOnsic21hcnRDcm9wIjp7InBhZGRpbmciOjYwfSwicmVzaXplIjp7IndpZHRoIjo2MCwiaGVpZ2h0Ijo2MCwiZml0IjoiY292ZXIifX19

https://dronework-images.s3.eu-west-2.amazonaws.com/wp-content/uploads/2022/06/20140319/FCPX-DRONE-EDIT-1.png

[theopape]

{ "requestId": "17dc59bb-9a51-44cd-a4df-ab3241e31f82", "ip": "xxx", "user": "-", "caller": "-", "requestTime": "22/Jun/2022:15:43:37 +0000", "httpMethod": "GET", "resourcePath": "/{proxy+}", "status": "400", "protocol": "HTTP/1.1", "responseLength": "96" }

[fisenkodv]

@theopape the first link you provided returns java.nio.HeapByteBuffer[pos=0 lim=5488163 cap=5488163]. Could you please confirm it still points to the Serverless Image Handler?

[theopape]

{
  "bucket": "dronework-images",
  "key": "wp-content/uploads/2022/06/20140319/FCPX-DRONE-EDIT-1.png",
  "edits": {
    "smartCrop": {
      "padding": 60
    },
    "resize": {
      "width": 60,
      "height": 60,
      "fit": "cover"
    }
  }
}

[theopape]

This is the request that we make to the Serverless Image Handler with that URL ^^

[theopape]

We think the issue is that Rekognition doesn’t support webp

[fisenkodv]

@theopape based on the request you provided above, your image in the PNG format wp-content/uploads/2022/06/20140319/FCPX-DRONE-EDIT-1.png. Also, the Serverless Image Handler converts the image to the Rekognition compatible image format if needed, see here https://github.com/aws-solutions/serverless-image-handler/blob/b6a4f88567ba7a1f2c64978f9a2edd0051c4e938/source/image-handler/image-handler.ts#L429

We will look into it and add it to our backlog.

[theopape]

OK thank you. So this will allow a larger PNG file to be sent to Rekognition?

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[theopape]

This is still an issue. Please let us know that you are looking into it.

[dougtoppin]

@theopape yes, it is in our backlog, we will try to get to this soon and let you know what we find

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[simonkrol]

Hi @theopape
I've done some investigation on this issue. I believe that the problem has to do with how metadata exists on sharp images. Sharp metadata is set on object creation and is not updated as filters are applied. What this means is that when we try to generate the Rekognition compatible image, the metadata indicates that the image is a PNG (since thats what it was when the Sharp object was created), despite having applied an edit to format it as a WEBP. In these cases, we skip the reformat (since we think the image is already in a valid format), and Rekognition errors us since we're actually giving it a WEBP file.

This is a bug on our end and I'll set up a task to have it fixed. In the meantime, you should be able to workaround the issue by moving the toFormat edit later than the smartCrop edit (since edits are applied sequentially).

Something like:

{
    "bucket":"dronework-images",
    "key":"wp-content/uploads/2022/06/20140319/FCPX-DRONE-EDIT-1.png",
    "edits":
    {
        "smartCrop":{"padding":60},
        "toFormat": "webp", 
        "resize":{"width":60,"height":60,"fit":"cover"}
    }
}

should work for now.

[simonkrol]

Hi @theopape,
With v6.2.5 of the Serverless Image Handler, toFormat should now with smartCrop regardless of the order of your edits.

Thanks for bringing this to our attention,
Simon