Image compression - Fireworks v Photoshop

[JohnGordon1972]

Just a quick question on this. I have been using Fireworks since forever, even though I should probably have ditched it a long time ago, I've always just kind of gotten on with it for odd things, mostly when I need to resize and prep images for websites etc. So nothing too demanding, or anything that made me make the leap to Photoshop which was less familiar to me, and maybe seemed like overkill.

But now that I subscribe to CC, I figure I may as well use PS, now that FW isn't supported and can be a little buggy these days.

So, I have a large image - about 5,600 x 3,800px and about 8MB .jpg

Just to test it in PS, I exported it out to a .jpg, 1920x1280 px, at 80%. Which got it down to 984k.

Out of interest, I did the same in FW, but that got it down to 434k.

As that's a reasonable difference, and I would maybe have expected the current version of PS to do a better job than a year's old version of Fireworks, I'm wondering if there's anything I've missed?

Any pointers on this would be much appreciated, as I figure I may as well do it as properly and efficiently as I can!

Thank you!

[JonathanArias]

i would stick to working in photoshop/ FIREWORKS is not even used anymore, It like comparing Go live to dreamweaver. What does it matter? one of the programs is not even used anymore..

[davescm]

It is hard to compare like with like as the quality setting, which impacts compression, does not have a standard between apps. So "80%" in one app can apply a different level of compression to "80%" in another.

Dave

[D Fosse]

JohnGordon1972  wrote

I would maybe have expected the current version of PS to do a better job than a year's old version of Fireworks

Actually I would expect the opposite. Back then it was much more important to reduce file size at almost any cost.

I don't know if the compression factor comes in discrete, absolute steps, but I suspect not. The Photoshop dial goes to 12, the Export/SFW dial to 100. In that case, I might suspect that Fireworks cranks the compression up a bit compared to Photoshop.

EDIT: Dave answered that for me. Yes, I'm fairly convinced that's it. What else could it be - as long as both strip away any metadata? There aren't "alternative" ways to compress a jpeg.

[c.pfaffenbichler]

Can you post the two images?

Are the profiles embedded?

Is there metadata?

[JohnGordon1972]

Thanks for the replies - its mostly out of curiosity and just to make sure I wasn't missing something that I should have been ticking or selecting when doing the export. I'm certainly not about to say its any sort of dealbreaker or anything if that's just how it is, and its fine.

The two images are here:

Photoshop

http://www.wildlife-planet.com/images/elephants_hero_compressed_PS.jpg

Fireworks

http://www.wildlife-planet.com/images/elephants_hero_compressed_FW.jpg

[c.pfaffenbichler]

Put the images atop one another in Photoshop and view at a large magnification – the FW saved one seems to be considerably less »sharp«.

[D Fosse]

Yep, that explains it. High-frequency detail eats up kB's fast with jpeg.

[JJMack]

Yes image content effect how well compression works more details bigger file. Processing images changes images details. Noise increase details. Textures etc.  Some  Application and web sites may do some default processing of image.  Every time you save a jpeg the image is encoded and some image quality is lost you are saving the next generation not what you opened and the application may have modified what was opened. Also you are using the jpeg encoder that application uses.

[JJMack]

Some of you files may have contained ancestor metadata that was striped during your saving and testing.  An 8MB jpg is not usual except from a cameras Application like photoshop save at high quality compression not uncompressed. Changing your large image down in size to 1920x1080 reduces the number of pixels. Pixel data is the bulk of image file data. 1920x1080 image file size will be much smaller than large image files.  Also every save encode the image in the application which if jpeg is not exactly like the image that was encoded.  Each generation looses some image quality.   You can save many times during an edit session all are encoder from the image in memory the  decoded image your are working on.  All the save would be in the same generation.   Its the decode encode decode encode sequence that separate generations.

[rayek.elfin]

Jpg compression and quality depend on a number of factors. Photoshop doesn't provide direct control over Chroma subsampling, for example. Other jpg compression tools may remove the extra meta data.

Anyway, the original PS image can easily be optimized down to around a little less than 500kb without hurting the image quality. I used both RIOT and Photoshop's old Save For Web option, and both reduce it to around 480-490kb while the quality remains visually pretty much identical. I always zoom in to 200% or 400% and compare the original with the compressed version. If I can hardly see any difference (barring some barely noticeable artefacting near some edges) I know it's more than good enough.

And Dfosse is correct: the Fireworks version is visible softer even when I visually compare it at 100% - which means Fireworks used a higher compression factor and/or softened the image (which is also often an additional option in apps' jpg compression settings).

[JohnGordon1972]

Thanks everyone - it was out of interest as much as anything, so always good to just try and understand a bit more about why things are doing what they are doing.

For something like a large background image on a website, what sort of file size should I be aiming for? Under 1MB sounds not too bad for me, but even that might be a bit big.

Its a little 'how long is a piece of string', and I suppose as time has gone on and we've had to try to be good at making things as small as possible, connection speeds have increased which kind of offsets that, at least in part.

[Test Screen Name]

If talking about size limits I’d say it’s more useful to consider the total image load on the page, not a per-image limit.

[rayek.elfin]

I wish webp would be supported better in all browsers. It really is time to replace the aging jpg with the far superior webp. Just the global savings on bandwidth and electricity usage would be gigantic.

[JJMack]

In that gigantic savings calculation did subtract the  man hour cost of adding support for webp in all image application and cost to convert  all jpeg image to webp. The cost seem to be be quite gigantic as well.

[rayek.elfin]

It would be a gradual migration to webp, of course. No need to convert old images. And webp is already supported in many image editors either native or via a plugin (even Photoshop).

[JJMack]

The gradual migration is just so gradual you can not see its movement. It movement may seed up in time, like high resolution display UI support did. The problem was first notice  in 2001 when a high resolution displays was introduce into the marketplace. For more than a decade there was no movement at all. Then in 2017 Adobe took notice and now in 2018 we have working support.

[D Fosse]

rayek.elfin  wrote

It really is time to replace the aging jpg with the far superior webp.

No argument from me. The problem is that jpeg, for most people, is good enough. There's no real incentive.

I suspect this is one of those things that would have to be forced to get any traction. Say what you will about Apple (and I have on many occasions) - but they understand this. Would 4K displays have happened if Apple didn't hold their customers hostage to retina and denied them any choice? I doubt it. After all, it mainly makes people's lives complicated.

With that in mind, I think HEIF has more of a chance than webp.

[JJMack]

Its technology some things take longer to die the others. Look at how long records were around, then there were tapes, then cd followed by mp3, now music is streams. However I hear that records are making a comeback will they ever die out.  The wheel is still hanging in there and don't forget fire. Some things will never die. I'll die before Jpeg they work OK.