Just upgraded to Build 3 of Storyline 2. Still having image quality issues. Images are screen shots taken with Snag It and pasted in email to me. I save images and insert in SL. My images look ok on my screen but when published they are looking blurry, particularly the larger ones. I have been reading on other threads about getting the exact right ratio, and how SL resizes images automatically.
I need help -- I come from Adobe and graphics background so it's illogical to me that larger images sized down would sacrifice quality. Can anyone offer advice? I am stumped. Thanks.
Have you tried them as actual image files instead of using an image that was pasted into an email? I'd imagine the original image files quality may behave a bit better than using a copy/paste. Also, you can change the publishing quality settings as shown here:
Thank you for your reply, Ashley! I right-click and save the images from the email as separate files. Then I insert into Storyline. Thinking I should try having the original screen shots saved by my client as image files. But I do think the issue lies with SL. Images look fine and preview fine. After publishing is when quality is diminished. And I have the Image Quality slider all the way to the right. Just FYI.
Storyline will always have some element of compression - but the quality settings are a good way to override that. I know a few users have also looked into modifying the published output and replacing the image files there to use the original, although I can't provide support for any modifications of the published output.
Screenshots are an odd thing they are actually better if saved as gifs because of the compression used in jpgs. You should avoid shrinking the image because the image is already pixel perfect at its resolution shrinking the image will cause pixels to be knocked out and image quality to deteriorate and artefacts to appear.
The key thing with screenshots is to try not to resize, perhaps you could get them to retake the screenshots at a lower resolution
Thanks, Phil. The original images are usually PNG or JPG. GIFs are only 256 colors so it surprises me quality would be better. I am willing to try anything so I am on it. Thanks so much for the tips.
If they are text based images then you can likely take the colours down to 16 and not notice any difference. If they are graphical images such as high quality websites then use pngs as the compression is much less than jpgs. You should never use jpg for screenshots compression is just not suited for this type of image. This is one of the reasons the iPhone/ipad will use pngs for screenshots but jpg for photos
Thanks for clarifying, Phil. They are screen shots of a software program so I might be able to get away with GIFs. I will be experimenting and will post my solution, when I find one. Thanks to you both for your quick response. I am impressed how quickly you jumped on to help me.
Just chiming in here as Phil's comment could be confusing - the rule of thumb for choosing a compression format is:
GIF & PNG - use if the image is mostly flat colour or a very limited range of colours e.g. a logo or an icon
JPEG - use if the image has a lot of different colours e.g. a photograph
Phil's comment about the screen shot is correct if what was on screen at the time was mostly flat colour, but incorrect if what was on screen has a lot of different colours.
Of course the above is for the source graphic that you're importing. Once in ASL it's then subject to how ASL then compresses graphics when it publishes. At this stage I'm unsure if there is any advantage to compressing source graphics before importing, it may be a waste of time because of what ASL does. My approach currently is not to worry too much about source compression and rather to import reasonably high quality graphics to give ASL the best chance of creating a good quality outcome when it does it's compression.
Edit: I've just discovered that ASL2 has an issue with output compression. Even if you publish at 100% (full) quality ASL2 applies compression which can lead to soft graphics. So your best attempts at getting images just the way you want them could be thwarted by ASL2.
7 months have passed since Tim provided his comments, has anyone been able to solve the issue with the compression of graphics? A simple screen shot of a system appears pixelated, and I have found that trying to embed a video into ASL2 a showstopper because of the compressed output. For the record, the same images and video files imported into another produces better results.
I agree with Tim's comment about ASL2 and it appears as though ASL2 has introduced the problems. In addition to the issues with the graphics, I am also having trouble with the .html file launching from a local file share.
There will always be a certain element of compression based on the published output - but if you have an example you'd like our team to take a look at we'd be happy too. You can upload it here to our Support Engineers.
10 Replies
Hi Sally,
Have you tried them as actual image files instead of using an image that was pasted into an email? I'd imagine the original image files quality may behave a bit better than using a copy/paste. Also, you can change the publishing quality settings as shown here:
Thank you for your reply, Ashley! I right-click and save the images from the email as separate files. Then I insert into Storyline. Thinking I should try having the original screen shots saved by my client as image files. But I do think the issue lies with SL. Images look fine and preview fine. After publishing is when quality is diminished. And I have the Image Quality slider all the way to the right. Just FYI.
Hi Sally,
Storyline will always have some element of compression - but the quality settings are a good way to override that. I know a few users have also looked into modifying the published output and replacing the image files there to use the original, although I can't provide support for any modifications of the published output.
Screenshots are an odd thing they are actually better if saved as gifs because of the compression used in jpgs. You should avoid shrinking the image because the image is already pixel perfect at its resolution shrinking the image will cause pixels to be knocked out and image quality to deteriorate and artefacts to appear.
The key thing with screenshots is to try not to resize, perhaps you could get them to retake the screenshots at a lower resolution
Thanks, Phil. The original images are usually PNG or JPG. GIFs are only 256 colors so it surprises me quality would be better. I am willing to try anything so I am on it. Thanks so much for the tips.
If they are text based images then you can likely take the colours down to 16 and not notice any difference. If they are graphical images such as high quality websites then use pngs as the compression is much less than jpgs. You should never use jpg for screenshots compression is just not suited for this type of image. This is one of the reasons the iPhone/ipad will use pngs for screenshots but jpg for photos
Thanks for clarifying, Phil. They are screen shots of a software program so I might be able to get away with GIFs. I will be experimenting and will post my solution, when I find one. Thanks to you both for your quick response. I am impressed how quickly you jumped on to help me.
Just chiming in here as Phil's comment could be confusing - the rule of thumb for choosing a compression format is:
GIF & PNG - use if the image is mostly flat colour or a very limited range of colours e.g. a logo or an icon
JPEG - use if the image has a lot of different colours e.g. a photograph
Phil's comment about the screen shot is correct if what was on screen at the time was mostly flat colour, but incorrect if what was on screen has a lot of different colours.
Of course the above is for the source graphic that you're importing. Once in ASL it's then subject to how ASL then compresses graphics when it publishes. At this stage I'm unsure if there is any advantage to compressing source graphics before importing, it may be a waste of time because of what ASL does. My approach currently is not to worry too much about source compression and rather to import reasonably high quality graphics to give ASL the best chance of creating a good quality outcome when it does it's compression.
Edit: I've just discovered that ASL2 has an issue with output compression. Even if you publish at 100% (full) quality ASL2 applies compression which can lead to soft graphics. So your best attempts at getting images just the way you want them could be thwarted by ASL2.
7 months have passed since Tim provided his comments, has anyone been able to solve the issue with the compression of graphics? A simple screen shot of a system appears pixelated, and I have found that trying to embed a video into ASL2 a showstopper because of the compressed output. For the record, the same images and video files imported into another produces better results.
I agree with Tim's comment about ASL2 and it appears as though ASL2 has introduced the problems. In addition to the issues with the graphics, I am also having trouble with the .html file launching from a local file share.
Hi Bob,
There will always be a certain element of compression based on the published output - but if you have an example you'd like our team to take a look at we'd be happy too. You can upload it here to our Support Engineers.
This discussion is closed. You can start a new discussion or contact Articulate Support.