[MGNLIMG-335] WEBP dimensions have no value Created: 17/Oct/23  Updated: 20/Dec/23

Status: Accepted
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Roberto Gaona Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File png has height.png     PNG File webp has no hieght.png    
Issue Links:
Problem/Incident
causality
is causing RESPDAM-75 Support metadata for webp images in A... Open
duplicate
is duplicated by MGNLIMG-351 Webp images is not stored its width &... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Support
Team: Nucleus

 Description   

Similar to what happens with SVG images, it seems like uploaded WEBP images don't have metadata properties values to reflect their dimensions.

This could be caused by the library used to retrieve the image dimensions (org.devlib.schmidt.imageinfo.ImageInfo).

 

Steps to reproduce

  1. Open Asset app
  2. Upload webp image

Expected results

Webp images should be stored with its width & height like other types (ex: png)

Actual results

Webp images is not stored -1 value instead of its width & height

 

NOTE:

Definitly solve for WebP.

Solve for SVG as well if possible.



 Comments   
Comment by Marvin Boie [ 12/Dec/23 ]

The problem here seems to be that the lib org.devlib.schmidt.imageinfo.ImageInfo was last updated in 2006 and WEBP was released in 2018.
My suggestion to get the image dimensions  here would be to replace ImageInfo with ImageIO, as there is already WEBP support for this in Magnolia and I can confirm that the image dimensions can be read out with it:

 

long imageWidth;
long imageHeight;
try {
    final BufferedImage read = ImageIO.read(image.getContentStream());
    if (read != null) {
        imageHeight = read.getHeight();
        imageWidth = read.getWidth();
    }
} catch (final IOException ignored) {
} 

Tika could be used to get the MimeType, but not java.net.URLConnection#guessContentTypeFromStream, this method already causes problems with IMGREC-88

My comment from IMGREC-88 may also contain some information relevant to this ticket.

 

Generated at Mon Feb 12 02:14:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.