Skip to content
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

[Suggestion] Add jpg and png as supported file suffixes for cover art #78

Open
Olf0 opened this issue Mar 12, 2024 · 3 comments
Open

[Suggestion] Add jpg and png as supported file suffixes for cover art #78

Olf0 opened this issue Mar 12, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@Olf0
Copy link
Contributor

Olf0 commented Mar 12, 2024

Currently the C++ code only supports the file suffix jpeg and jpg, see https://github.com/search?q=repo%3Asailfishos-applications%2Fflowplayer+path%3A%2F%5Esrc%5C%2F%2F+media-art%2Falbum&type=code

All these location might be altered to also accept png.
Note that only this code section is already prepared for this: https://github.com/sailfishos-applications/flowplayer/pull/75/files#diff-380f2b4fb214da5db2e2f6c4d0c1f8d22f2d74b1fbe40671cb3966c6900fc6b6R217-R232

@Olf0 Olf0 added the enhancement New feature or request label Mar 12, 2024
@Olf0 Olf0 changed the title [Suggestion] Add jpg and png as supported file suffixes for cover art. [Suggestion] Add jpg and png as supported file suffixes for cover art Mar 12, 2024
@dcaliste
Copy link
Collaborator

One solution would be to transcode the PNG into a JPEG file in the routine looking for cover art. I mean, copy (as done now) if the source file is a JPEG one, and use QImage to transcode into a JPEG if the source file is in a different format.

@Olf0
Copy link
Contributor Author

Olf0 commented Mar 13, 2024

One solution would be to transcode the PNG into a JPEG file in the routine looking for cover art. I mean, copy (as done now) if the source file is a JPEG one, and use QImage to transcode into a JPEG if the source file is in a different format.

Absolutely true, that would alleviate the need to alter many code locations, the only drawback is the loss of image quality, which can become well visible if an image contains high contrast edges.

@Olf0
Copy link
Contributor Author

Olf0 commented Mar 14, 2024

Thinking about it, technically it would be better to transform al cover art into a lossless compressing format: The best candidate is likely PNG.

This still would be not very intrusive (simply exchanging the extension JPEG with PNG at all these locations), but might require a migration function, or discarding and rebuilding the cover art cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants