Jump to content

Cre8asiteforums Internet Marketing
and Conversion Web Design


Photo

Scaling Images In The Page What Does It All Mean!


  • Please log in to reply
8 replies to this topic

#1 glyn

glyn

    Sonic Boom Member

  • Hall Of Fame
  • 2628 posts

Posted 20 November 2014 - 07:53 AM

If you have a web-page that loads an image like this:

 

/images/prod/image.JPG?width=150&height=150&bgcolor=ffffff&scale=both

 

What is going on?

 

For example when I remove from the ?forwards I get the full image. My question is whether the web-page loads a full images and just reduces the size, or whether the image is cropped and then served.

 

If I have a product page with 50 of these typ of images am I loading 50 biggies and then shrinking them, or am I essentiually loading 50 shrunk photos?

 

Thanks

 

Glyn



#2 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 2197 posts

Posted 20 November 2014 - 10:47 AM

One way to find out is to view the image info with your browser. If a biggie it will say something like 600x600 (scaled to 150x150). Then you transported a large image and the browser did the scaling... now you use up bandwidth.

 

I presume if it says 150x150 and no scaling then the image is really 150x150 but if you know for a fact that it is really a 600x600 biggie then the server has reduced it before serving it.... and this eats up CPU cycles.

 

Save a copy of the image on your computer and check the size.



#3 glyn

glyn

    Sonic Boom Member

  • Hall Of Fame
  • 2628 posts

Posted 20 November 2014 - 10:51 AM

Yes, image is smaller, yes it is done on the server.

 

WTF would you do it this way? Why would you not create a smaller version of the image when you upload the big image? Lazyness?

 

Someone defend the idiots I'm working with.

 

G.



#4 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 13644 posts

Posted 20 November 2014 - 10:53 AM

Responsive design?

 

(She guesses, pushes button and hopes she wins points in this game-show  :cheerleader: )



#5 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 2197 posts

Posted 20 November 2014 - 11:03 AM

How much of a difference 200x200 to 150x150 or 600x600 to 150x150? I presume a big one if it caught your attention.

 

Maybe a rush to get to market? :) Maybe the large image is used somewhere else?

 

There is no defence.

 

I don't think responsive design is the answer either. In this mode you send the original image and let the browser render it accordingly.

 

Now if you do go the route of resizing those images permanently, to save CPU, also remember to take out that code which causes the resize to happen on the server otherwise it will still use CPU to execute that process to just do nothing.
 

My question is whether the web-page loads a full images and just reduces the size,

For the browser to do this the dimensions have to be coded in the <img tag and this is good.


Edited by bobbb, 20 November 2014 - 11:27 AM.


#6 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 2197 posts

Posted 20 November 2014 - 12:24 PM

<sarcasm>

I've just thought up a defence and it was so obvious. You let a computer do all the heavy lifting. This is how things are done today which accounts for all the bloat you have around everywhere. Things are slooow? A faster computer is the solution. In your case this is true. Get a new Zeon with a quadrillion cores with a few yottabytes of memory. Fiber optics will solve all the bandwidth issues.

 

You have a good idea. Press a button and a computer will design it for you and voila there is the solution.
</sarcasm>

yottabyte 1024 to the power of 8



#7 TheAlex

TheAlex

    Gravity Master Member

  • Members
  • 236 posts

Posted 21 November 2014 - 03:03 PM

Yes, image is smaller, yes it is done on the server.

 

WTF would you do it this way? Why would you not create a smaller version of the image when you upload the big image? Lazyness?

 

Someone defend the idiots I'm working with.

 

G.

 

Because it's time consuming! I haven't used it yet, but this looks good for resizing images on the fly: http://adaptive-images.com/



#8 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 2197 posts

Posted 21 November 2014 - 08:03 PM

From what I read and understood the article describes a method that will eventually create, in a cache, a proper sized images for all the breakpoints in responsive design. This is good. I presume the whole cache could be pre-created and loaded into the proper cache area and no resize would ever occur. The php file which handles <img tags would just pick the correct pre-created image. This is better. In theory this would not be all that time consuming at run time. A really good idea for responsive design.

I think in G's scenario the resize is occurring every time with the hard coded parameters: /images/prod/image.JPG?width=150&height=150&bgcolor=ffffff&scale=both

Scale=both implies, to me, that 150x150 is the max size and an image could end up being 140x150 if the large scale image were in that same ratio. I think his gripe was why not scale them to those specs beforehand and skip those CPU cycles at run time. So my sarcasm still applies.

 

If I were G and had this situation I would actually give the code in that article a try with or without the pre-created images I mentioned. It can't be worse than doing a resize every time. Again I presume he is trying to address a load time issue.


Edited by bobbb, 21 November 2014 - 08:13 PM.


#9 Grumpus

Grumpus

    Honored One Who Served Moderator Alumni

  • Hall Of Fame
  • 6344 posts

Posted Today, 05:21 AM

I've seen this done with a php extension on the file. Basically, you don't link to images directly, it goes through a processor. So when you click "View Image" (or whatever) it doesn't link to "file.jpg" it links to "file.php?data=info" which then uses GD to scale the image. This will cache a properly sized image both on the server and in your browser cache.

 

I suspect with a little mime jockeying (or some other technique) you could make it so you can call file.jpg and have it go through your GD scripts.
ADDED: I was curious about this, so I looked. Here is the answer to "how". So now your php can get EXACT numbers that adapt to values relative to it's container.

Is this lazy? Maybe sort of, but it is also more adaptable. Using javascript, you can create a JSON object that reports the EXACT size of someone's screen. You can then dynamically create your CSS (call css.php rather than css.css) and that php generated CSS can have math that creates a CSS file for ANY SPECIFIC resolution. How many different screen sizes are there today? How many will there be in 2 years? 5 years? 10 years?"

 

Currently we're making CSS with several different cut-off-points and then dynamically scaling things within that. What if you could have one cut-off point to determine "full screen - two columns" and "small screen - stack into a single column and adapt interface". And THEN you could stack that page with specific dimensions? And your images could be a specific width rather than a percentage of an arbitrary number. And imagine if those images were cached and delivered at their proper size rather than being scaled as a percentage that probably doesn't fit into the Rule of 8s?

True, this site probably isn't doing ALL of that... but the Rule of 8's bit is probably what they are dealing with right now. (I'm not sure what this rule is actually called - I just call it that). If you aren't familiar with the Rule of 8 - basically, in web and graphic design for the web, every number you use and every graphic resolution you make should be divisible by 8. All screen widths do this. 800x600, 1024x768, etc. If I create a graphic and need to scale it, if it starts at a number that is divisible by 8, then there is very little loss. 50% of an 800x600 graphic is 400x300 - another number that is divisible by 8. This means that every line and row of pixels was used when figuring out how to scale the graphic. If I started with something that was 807x298, and do the same division, there are certain rows and columns that are just going to end up being discarded or unevenly represented in the scale model. This makes the image look blurry - whether you are scaling it with CSS or in phothoshop before you upload it, or whatever.

 

You're 50x50 example doesn't fit into the rule of 8, but it could fall into the rule of 2 - which can be just as good if you are consistent in your divisors - 50% (and 25%), 20%, 10%, etc.

Now, let's look at responsive design...

When we make our CSS sheets we don't account for every screen size. We usually pick 3 or 4 and deal with those. The thing is, none of the numbers we pick are "real" numbers. They are "if it's less than" type numbers we'll do things like @media screen (max-width:699px;) and @media screen (max-width:299px;) or whatever. At that point we still don't know the exact size of the screen. If it's hitting the 699 screen, it could be 640. It could be 480. It could also be 600, 540, or 360.

So, here's the thing... if you REALLY want to "not be lazy" and upload an appropriately scaled image and have a style that will format it, you need to make one for EVERY screen width on this page. And you also need a CSS declaration, too. I've got a big shiny quarter, a nickle, and three pennies in my pocket that I would wager to say no one here is doing that.

Maybe (I'd bet "probably") the site in question is declaring many more than the typical 3 in their CSS, and then dynamically generating an image to scale with the least amount of loss. They MIGHT even be doing what I described above and dynamically generating the CSS to match ANY resolution, too, but even if they aren't and they are just taking into consideration desktop monitor, tablet horizontal, tablet vertical, phone horizontal, phone vertical - that's 5 different sizes, with 5 more thumbnail versions to make - for every graphic you're going to put in there.

 

Sorry to disagree, but ultimately, this isn't lazy. It's where responsive design is going next. You've stumbled on the future - embrace it. ;)

 

G.


Edited by Grumpus, Today, 05:45 AM.




RSS Feed

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users