Blurry images in Storyline 360 November 2021

I also did a double take on the filetypes listed as being bad for scaling!

Deleted a post kind of critical of something Michael said: "there is some resizing going on which isn’t ideal for image formats that do not scale well like SVGs, EMFs, or WMFs"

After re-reading that line a few times I realised he was saying "like" to mean "as well as"...

Apologies.

I also misinterpreted the "like"!

Hi Mark. I took the liberty of peeking into your file and checking things out. I completely understand your frustration because I can find no reason why it displays blurry upon preview or publishing.

One caveat; I notice a lot of folks do this so it's not pointed at you - PNGs are only necessary to use whenever your bitmap image has a transparent section. If it doesn't then a JPEG is the optimum file format. The reason is that PNGs tend to be far larger in 'size' than JPEGS.

Which brings me to JPEG image compression.

Generally, the more compression applied to a JPEG upon export the more degradation there is in the image (blurriness, pixelisation, artefacts, etc). I have uploaded a version of your file to Review with 4 buttons that show whatever differences there are between the formats and compression.

Weirdly, there is little or no difference in the visual result between your original PNG (2048x1536px which scales down to 720x540px in the SL360 file), a straightforward high quality (zero compression) JPEG and a resized JPEG (720x540px import - actual size).

The only noticeable difference is in the third option which was the original size JPEG compressed to Very Low Quality (10) and the result is predictably bad. 

But what is concerning is that this deliberately bad image is not really that far off from the other 3. So yeah, conclusive proof that I have no idea what is happening to your image. there is no reason, AFAICS, for the quality to publish so poorly.

Not sure if this helps at all.

https://360.articulate.com/review/content/e203cc0d-6e22-4864-95f4-d0b4a3866d2b/review

Hi Diarmaid,

It does help, because at least I don't feel like I'm expecting something unreasonable. It's crushing to see your work almost vandalized when you publish it. People naturally assume it's incompetence from the author, either in the creation of the material or the selection of the delivery platform.

Yes, yes, yes! You have captured the issue perfectly Matthew (and Diarmaid).

Wow. That's meticulous research dude. That's amazing, the difference.

Thank you everyone for your patience, and apologies for the slight confusion on the file types! Let me take your findings back to the team Matthew so we can review this function of Storyline 360.  I just want to confirm that when you say you "replaced the published image with the original", this means you went into the Storyline output\mobile folder after publishing and replaced the processed image with a raw version of the same image?

EDIT: Nvm, I just saw your earlier post confirming this. Thank you.

I really appreciate the extra effort you've all put into this.

- Michael Marcos
Customer Support Product Liaison 

Full disclosure - I don't generally import images with text in them so I don't encounter this issue that often. It's clearly obvious that text is affected. I think there is probably more leeway with images without text. I, unfortunately, tend to recreate any charts, diagrams or text images within Storyline itself to bypass these publishing issues (yet another productivity limiting 'hack' or workaround that's been embedded into my workflow).

But, from the link I posted a little bit further up, there is (was) clear degradation in image quality if the image is embedded in a non-rectangular frame. This may be fixed now but if I require bespoke image 'frames' I do it outside Storyline and import the image as a transparent PNG - just another workaround to broken Storyline functionality. I have not tested if it's fixed.

But at least we know arrows are no longer blurry.

I'm just circling back here to let everyone know that we will be taking investigating this further on our end. The results Matthew got from the steps he documented earlier are not expected behavior. I can't give an ETA on how soon it will take to fix this as that can change depending on how complex of an issue the original image quality issue may turn out to be though.

Thank you again for your patience as we continue to chase down this issue!