Person entity pictures are cropped/saved as JPG instead of PNG which loses transparency

[kevingrubbs]

Checklist

• [X] I have updated to the latest available Home Assistant version.
• [X] I have cleared the cache of my browser.
• [X] I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

Uploading a picture with a transparent background (PNG) to the person entity loses transparency and ends up black, as it is saved as JPG.

Previously, the person entities in my home assistant I was adding a picture element through the customization.yaml pointing to a local PNG file (/local/kevin.png). With the upgrade to 2022.12.1, these no longer showed up. So I went to the People page and looked under the person entity, and see there's a picture control there. The picture I'm uploading has a transparent background. But after cropping, the transparent background turns black. This looks bad on a "light" theme, as all my pictures are bitmojis of the people in the system, with a transparent background.

Describe the behavior you expected

I expected that the background of a person entity could be transparent as it was before. Likely this just needs to be output as PNG instead of JPG.

Steps to reproduce the issue

1. Go to the Settings > People page
2. Click on a specific person
3. Click on Picture
4. Select an image with transparency (I used png format)
5. Update cropping as necessary
6. Click Crop
7. See it already has a black background, click update
8. Go to front end where showing person card, see it is black background. ...

What version of Home Assistant Core has the issue?

core-2022.12.1

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

Firefox 107.0

Which operating system are you using to run this browser?

macOS Monterey (12.1)

State of relevant entities

editable: true
id: kevin
latitude: <removed>
longitude: <removed>
gps_accuracy: <removed>
source: device_tracker.kg_iphone_12
user_id: 9085691a649c4353adbd0f46356b72c3
entity_picture: /api/image/serve/eafb8f31238039a8edeff797ba387a4e/512x512
friendly_name: Kevin

Problem-relevant frontend configuration

entities:
  - entity: person.kevin
show_icon: true
show_name: true
show_state: true
type: glance

Javascript errors shown in your browser console/inspector

none

Additional information

I don't know what version the "picture" element was introduced on the person entity, so I don't know if this was ever working or not. I just know the customization.yaml approach that I was using stopped working when I upgraded today to 2022.12.1.

Potentially customization should still be supported, but if that is phasing out in favor of this approach, transparency should continue to be supported IMO.

[bramkragten]

This is not a frontend issue, the backend resizes/reformats these images.

[blacknell]

@kevingrubbs did you find a related issue in core? I am seeing exactly this behaviour too and I feel it's a defect

[akston]

I'm seeing this issue as well. @blacknell @kevingrubbs I don't see an issue filed for this in core. Have you found some way to resolve this, or should I go ahead and file one?

[blacknell]

I'm seeing this issue as well. @blacknell @kevingrubbs I don't see an issue filed for this in core. Have you found some way to resolve this, or should I go ahead and file one?

Yes, please. Can you reference this issue (which I think should be closed if it does belong in core)

[akston]

Okay, I've spent some time digging into this, and I think I've got it sorted. Turns out this is a frontend issue.

CropOptions.type is being explicitly set in src/panels/config/person/dialog-person-detail.ts, which forces _cropImage to set type to image/jpeg in the callback and args passed to toBlob() in src/dialogs/image-cropper-dialog/image-cropper-dialog.ts.

From my very cursory understanding, explicitly setting CropOptions.type is unnecessary since _cropImage will fallback to the MIME type of the file if left unset.

I'm unsure when this problem started, but I can't seem to find any recent changes that would have started triggering it. I've tested in 20230406.1, and removing the explicit setting of type restores the correct behavior.

I've also confirmed that this doesn't affect functionality with JPEG or GIF images.

[blacknell]

Awesome. Well done.

[akston]

FYI: This is live as of 2023.4.4 (frontend 20230411.1).

[blacknell]

Yes. I already installed and it worked perfectly. Thanks for the fix. RegardsPaulOn 14 Apr 2023, at 14:59, akston @.***> wrote: FYI: This is live as of 2023.4.4 (frontend 20230411.1).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[akston]

No problem, glad to help and it was driving me nuts as well! 🤣