The "Freeola Customer Forum" forum, which includes Retro Game Reviews, has been archived and is now read-only. You cannot post here or create a new thread or review on this forum.
When starting to build the site I had tried "Breeze", one of the samples, to gauge the effect of a banner, although I intended to replace it with a photo of my own. The pic. I finally uploaded was 41.8Kb after cropping, size reducing and compacting. How then has it increased 4-fold? The HTML shows the banner as "Breeze", not my photo number. Is this, somehow, the answer?
But if so, it doesn't account for many other images I have checked on other pages. Two I uploaded at 37.2Kb and 38.7Kb show up as 385Kb and 362.75Kb respectively. 10-fold increase! Not only do they all differ from what I uploaded, but what is stranger is that some increase in size and others decrease.
What is going on?
My site is www.hedera.ukpc.net, although you have only my word for the fact that the pics. change size in mid-air before landing.
Help, somebody.
Thanks.
> The point was that uploading and image of size 50k would result
> in a 200k image with the quality set to 100%, i.e keeping the
> quality the same as the original. So it appears that 100%
> actually attempts to increase the quality and therefore the file
> size.
> GD's default quality is 75 so I'm guessing that setting it higher
> than this introduces interpolation or increases the DPI. I can't
> find any evidence of this on PHP's site though.
I dont think so.
Load an image into GD and what you have is an image resource. This isnt a jpeg (or any other file format). Its just raw uncompressed image data, format specific things like quality are gone. When you call imagejpeg, it takes this raw data and applies the jpeg compression to it with the quality specified.
> Bug? Is it really any surprise that 100% applies little
> compression to the image? :) I seem to recall that compression
> isnt linear either.
The point was that uploading and image of size 50k would result in a 200k image with the quality set to 100%, i.e keeping the quality the same as the original. So it appears that 100% actually attempts to increase the quality and therefore the file size.
GD's default quality is 75 so I'm guessing that setting it higher than this introduces interpolation or increases the DPI. I can't find any evidence of this on PHP's site though.
> Bug? Is it really any surprise that 100% applies little
> compression to the image? :) I seem to recall that compression
> isnt linear either.
TBH I would have imagined 100% would not make a change at all. It would just keep it at it's highest quality. But 80% seems to do that with GD... if I wanted to increase quality and thus size 120% would make more sense. Ahh well, well done Eccles!
... That's weird saying that with Eccles sitting opposite me lol
> Techy bit: The issue seems to be with the GD library that PHP
> uses to manipulate images. When we process the banners we resize
> them proportionally to fit on your site and save them with the
> image quality set to 100%. However it seems that GD has a bug
> with 100% image quality and somehow makes the file huge without
> doing much else! Having the quality at 80% produces no noticeable
> drop in image quality and file size is maintained, increasing
> quality just a couple of percent introduces the problem again!
Bug? Is it really any surprise that 100% applies little compression to the image? :) I seem to recall that compression isnt linear either.
Thanks for reporting this issue. I believe I may have fixed this now. You can check this by re-uploading your banner. The image size should remain near enough the same or be reduced.
Techy bit: The issue seems to be with the GD library that PHP uses to manipulate images. When we process the banners we resize them proportionally to fit on your site and save them with the image quality set to 100%. However it seems that GD has a bug with 100% image quality and somehow makes the file huge without doing much else! Having the quality at 80% produces no noticeable drop in image quality and file size is maintained, increasing quality just a couple of percent introduces the problem again!
I agree 175k is rather large for a header graphic.
I'm guessing the InstantPro editor has 're-processed' this possibly when you added the text overlay?
To investigate, I've created a 25k version of your banner including the text here
Perhaps you can experiment by using this as your banner and see if the filesize/filetype changes?
If you get stuck I'll try a test changing my InstantPro banner.
I've checked a couple of your other images sizes and the one's I looked at seemed fine. So perhaps this is a different issue. If you can say which images you've seen the problem with I'm happy to look.
For info.
Along time ago I created this page explaining the importance of image sizes for the web :¬)
[s]Hmmm...[/s] My Freeola Instant SiteEDIT: I see Freeola have also posted again while I did mine :¬)
I've just had a quick test and it does seem that we have issues with at least the banner upload. File sizes are definitely being increased even though there seems to be no reason that it should do this.
I'll do a bit more testing and get our Systems team to have a look into it. We'll post back here once we know any more.
Thanks.
The issue with your banner is unlikely to be caused by the "breeze issue" you have commented on. The only mention of the word breeze in your html is the css.... line, as breeze is the name of the template you have chosen in the builder.
The image was uploaded by yourself, and has to be re-sized and scaled etc if not the appropriate size I believe. I found a nice way of insuring the correct (or near to as possible) size was find the measurements, then edit your actual image to be the size needed before uploading. (702x? normally for the banner)
Meanwhile though I will check a few things myself, but I also know that some of the systems department will take a look.