Support compressed images and RGBA data in Image class

[luca-della-vedova]

🎉 New feature

Work towards #344 , specifically #344 (comment) to allow loading embedded textures.
Main user of this API would be gz-rendering, discussion on downstream API taking place in the gz-rendering PR

Summary

This PR adds support for loading compressed images from in memory binary blobs, this is achieved through a new SetFromCompressedData function that takes as an input a byte array and a format and loads the image internally. For now only PNG is supported but other formats can be added trivially by adding a new case to the if statement.
Since images are provided as binary blobs, height and width are not known when the function is called. An alternative approach could be to use SetFromData with the byte buffer being passed as an image of 1 * len(buffer) size, but I thought that wasn't too clean so went for another function.

It also adds a RGBAData function that returns the image in RGBA8 format. The main use case for this is that loading a PNG without an alpha channel through FreeImage would return an RGB8 24 bit image. This format might be tricky to use for downstream users because it's not aligned to the 32 bit boundary. This is specifically an issue in OGRE2 which is unable to transfer 24 bit textures to GPU (ref here).
Hence the convenience function is added for downstream users to make sure the image is always in a 32 bit RGBA8 format.

Note, I'm personally not a big fan of the API for the Data functions where a user has to remember to manually delete[] the pointer they passed as soon as they are done with it, it would probably be safer to either return a std::vector of bytes (at the risk of expensive copies happening if people are not careful) or a std::shared_ptr to a std::vector of bytes, which would make sure copies only increase the reference count and memory is still correctly deallocated.
However having this API would have required changing the behavior of the DataImpl function that is used in other parts of the library so I didn't quite know if this was a good idea.

Test it

Unit tests have been added, manual test is significantly more complex since it requires using the branches in #344 and the gz-rendering PR, having a GLB asset and making sure the asset is correctly displayed.

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[codecov]

Codecov Report

Merging #368 (e443ccd) into main (e94a691) will increase coverage by 0.04%.
The diff coverage is 100.00%.

❗ Current head e443ccd differs from pull request most recent head ccc483c. Consider uploading reports for the commit ccc483c to get more accurate results

@@            Coverage Diff             @@
##             main     #368      +/-   ##
==========================================
+ Coverage   77.88%   77.93%   +0.04%     
==========================================
  Files          84       84              
  Lines       10728    10750      +22     
==========================================
+ Hits         8356     8378      +22     
  Misses       2372     2372              

Impacted Files	Coverage Δ
graphics/include/gz/common/Image.hh	97.05% <ø> (ø)
graphics/src/Image.cc	73.02% <100.00%> (+2.31%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e94a691...ccc483c. Read the comment docs.

[mjcarroll]

However having this API would have required changing the behavior of the DataImpl function that is used in other parts of the library so I didn't quite know if this was a good idea.

I agree completely. Fixing this API has been on my someday/maybe list for a while. While it is out of the scope for this PR, if anyone on your side has some spare cycles, I would really appreciate a cleaner API before Garden.

[mjcarroll]

Windows failing is expected.

[luca-della-vedova]

However having this API would have required changing the behavior of the DataImpl function that is used in other parts of the library so I didn't quite know if this was a good idea.

I agree completely. Fixing this API has been on my someday/maybe list for a while. While it is out of the scope for this PR, if anyone on your side has some spare cycles, I would really appreciate a cleaner API before Garden.

I'm happy to look at it, I ticketed an issue #369 and can start working on it if the idea sounds reasonable to you.

[mjcarroll]

I'm happy to look at it, I ticketed an issue #369 and can start working on it if the idea sounds reasonable to you.

Great, thanks! I think improving this API will both make it more reasonable for users as well as make it generally more efficient as we are doing a lot of reallocations and copies.

[mjcarroll]

LGTM, I just added two more quick test cases so we can get 💯 coverage on the diff.