You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ability to customize Accept header for as many Deserializers as possible, but in particular the "identity" deserializers like BytesDeserializer and StreamDeserializer.
Sometimes we need to explicitly specify an Accept, but don't want the SageMaker SDK to do any processing beyond loading the bytestream.
In my particular case, I noticed that SDKv2 is materially harder to use than v1 with the built-in Semantic Segmentation algorithm - where we used to be able to simply:
Perhaps this is a deliberate omission, to encourage users to get familiar with implementing proper Deserializers rather than doing it after the predictor.predict() call? I could appreciate the rationale for that, it just doesn't feel very beginner-friendly.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Thank you for using Amazon SageMaker. Great suggestion. When I read the beginning of your issue, I thought the same thing myself re: passing in an accept to the constructor or, say, an associated classmethod.
Your current use of the implementation is correct, although the UX, as you noted, can objectively be improved. We are always re-evaluating our backlog of features based on customer requests, so we appreciate the feedback on this feature.
Describe the feature you'd like
Ability to customize
Accept
header for as manyDeserializer
s as possible, but in particular the "identity" deserializers likeBytesDeserializer
andStreamDeserializer
.Sometimes we need to explicitly specify an
Accept
, but don't want the SageMaker SDK to do any processing beyond loading the bytestream.In my particular case, I noticed that SDKv2 is materially harder to use than v1 with the built-in Semantic Segmentation algorithm - where we used to be able to simply:
Now I had to do the below to get the code working:
(Need to specify the Accept type for this algorithm, because default appears not to be PNG)
How would this feature be used? Please describe.
Directly re-use existing deserializers while being able to specify particular
Accept
:Describe alternatives you've considered
Perhaps this is a deliberate omission, to encourage users to get familiar with implementing proper Deserializers rather than doing it after the
predictor.predict()
call? I could appreciate the rationale for that, it just doesn't feel very beginner-friendly.Additional context
N/A
The text was updated successfully, but these errors were encountered: