-
Notifications
You must be signed in to change notification settings - Fork 861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support image bytearray in AutoMM #2490
Conversation
3ff219a
to
fa98433
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a minor suggestion for unit test.
326c69f
to
909b7c3
Compare
Job PR-2490-909b7c3 is done. |
Job PR-2490-0c15ed6 is done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the change. Some follow up actions in general:
- We should identify any doc/tutorial to be updated with this feature as it allows a new input type and we should make it visible via doc to the end user
- Can we build docker images for both GPU and CPU to see the inference impact on Sagemaker endpoint? If already done, ignore this point
@@ -156,6 +162,7 @@ def is_numerical_column( | |||
def is_imagepath_column( | |||
data: pd.Series, | |||
col_name: str, | |||
sample_n: Optional[int] = 500, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's add doc string for this field below as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for the suggestions! We can mention this feature in our tutorials in a follow up PR. The benchmark was done on a GPU instance and I can build a CPU endpoint as well. |
Job PR-2490-e973f14 is done. |
|
||
for img_bytearray in image_bytearrays: | ||
try: | ||
with PIL.Image.open(BytesIO(img_bytearray)) as img: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the image bytes are encoded by base64?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we enforce that the type passed into the predictor to be the original bytearray
? In the cloud serve scripts, I see that currently we would: 1. decode the encoded bytearray in a predefined way, and 2. save to disk to get the path to pass into the predictor. With the new feature, we can save step 2 by assuming no encoding on bytearray. If we are to expect encoded bytearrays in the dataframe, we would probably need to accept a callback decoding function provided by the user. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
base64 is used in encoding images in some cases. I think we'd better support users to provide base64 bytes in dataframe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
base64
is fundamentally a different format than bytearray
, since it is a text encoding rather than a binary encoding. We could consider adding a IMAGE_BASE64
column type, or we could try to make a more generic IMAGE_BINARY
type that also infers the encoding. But I think this is another feature request separate from the current issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since base64 requires additional decoding, we may define another type IMAGE_BASE64
. We can leave this to another PR.
return [_read_byte(os.path.abspath(os.path.join(base_folder, path))) for path in path_l] | ||
|
||
|
||
def shopee_dataset( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides unit tests, where do we use this dataset? It doesn't fit the context of this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is used in a few tutorials at the moment. Do you think creating a datasets.py
under the ./utils
will help?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually put the data preparation logic inside the tutorials, e.g., https://auto.gluon.ai/stable/tutorials/multimodal/multimodal_prediction/beginner_multimodal.html. Users can better understand what the data preparation in this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
c61a3ec
to
cc982b4
Compare
cc982b4
to
c7b339c
Compare
b082f97
to
5cce4b8
Compare
Job PR-2490-5cce4b8 is done. |
Issue #, if available:
Description of changes:
This PR adds support for image bytearrays in AutoMM.
The DataFrame column can be either
bytearray
orlist[bytearray]
.Benchmarking on the original
image_path
workflow with dataset on SageMaker endpointtest data:
100 x bytearray-encoded images
data preprocess:
0.5s to decode and save to disk to generate
image_path
to pass inMultiModalPredictor.fit()
predict_proba:
0.1s
With the support of bytearray, we can save the time spent on data preprocessing, which majority of the time is on saving the image to disk.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.