How did Google images normalize the width of each row? - image

It's easy to resize images so that they all have the same height while maintaining the aspect ratio, but how did they fit them all on a row such that every row has the same width? Did they crop some of the images or what?

Remember in google images (apart from cropping) -
Spacing between images are not always exactly same.
Height of all images in a row are also not always same.
Using above 2 techniques i.e. tweaking the spaces between images and changing size of image little bit by compromising height you can achieve this. In fact the the justify paragraph option in the text editor also use the spacing technique. They evenly distribute the extra spacing between all word.
You don't always get a good spacing in google image search. See this -
alt text http://dailycoding.com/filesharing/Google_image_search.jpg

they actually figure it out through an algorithm to put images next to eachother so with the padding and everything they end up being the same width then they cache that page for the keyword you searched for!

I found a very interesting article while looking for the same thing. If you look at google images you can see not all of the rows have the same height. but all the images in a row have the same height. So what you want to do is calculate the right height you need for the row so the images will fit (the images stretch if they get higher or lower). This article will possible help
http://blog.vjeux.com/2012/image/image-layout-algorithm-google-plus.html

Related

Using a TreeMap with images

For representing most popular artists from EchoNest API, I've been trying to set-up Silverlight Toolkit's TreeMap using images, their TreeItemDefinition.ValueBinding being defined as the area of the image.
While it mostly fills up the space when the image stretch is set to 'Fill' :
When setting image stretch to 'Uniform' a lot of blank spaces remain :
On this post, image carving is suggested : Treemapping with a given aspect ratio
How can I know which images should be carved and at what dimensions they should be carved if possible at all ?
Is this problem solvable without human intervention for a good result ?
I don't think there is a way to know which images should be carved and at what dimensions they should be carved. An ok-ish euristic might be to check if the mean energy of an image is > a certain threshold (this can be refined to check only blocks of every image, and combining the result later: if the image has blocks without details/energy, it can be carved, at least in that section).
What i think would be better is to apply seam carving to the already composed image: that will try to carve out the white outlines (adding "artificial" energy to the patches of images might lead to even better results, preserving more the shapes of each image). This paper might be of use to check out other image resizing methods too.

Bootstrap and images: What are the best dimensions to pre-resized images for a design implemented with Bootstrap?

I'm using a CMS (read: WordPress). While I realize that Bootstrap will adjust img sizing on the fly, should I (for example) have WP create a version of an image for each BS span# width? Or do you think having span2, span4, span6, etc. would be close enough and just just the slightly larger image for the next span down. For example, if you need an image in a span1, would you simply use the span2 image?
I'm trying to balance image size against being practical and reasonable.
Perhaps this isn't a StackoverFlow question? My apologizes.
Well, there are no such limitations or ideal sizes. People can use larger than 1000px width images or lower than 50px as well. It is the beauty of bootstrap, it automatically resizes image if the span width is smaller than image width.
So that should not really bother us while developing the theme. One thing you can take care of is, measure the most used span's width in Web developers tool and set ideal image size little smaller than span width.
You don't need another function to resize images. It would be an overkill.

Enforcing a particular width on a scale?

We have the customer requirement that for a particular scale of an image ('teaser' scale) the width has to the always 160px independent of the image ratio. Specifying as (160,160)
scale does not work for images where the height is larger than the width. In this case 160px will be used.
Any idea how to ensure a fixed with of 160px in every case?
I used this scales in a site and it worked OK:
image_scales = {'thumb': (150,600), 'mini': (200, 800)}
The idea is to have a very long height so no matter the image ratio of the picture, it will always be 150 or 200 px width.
In Plone 4 there is an entirely new way of generating scales which can help with this problem. Using this approach you can tell it to scale the image 'down' instead of 'up', which means that it will scale the short side of the image to the specified size, rather than the long side (so the image ends up getting cropped, but always fills the specified area).
With this approach, you don't have to define the scales in your schema, but can simply include something like the following in your template. The scale will be generated on demand.
<img tal:define="scale context/##images"
tal:replace="structure python: scale.scale('image',
width=160, height=160, direction='down').tag()" />
See the plone.app.imaging page for more examples of this approach to scaling.

Web Layouts: pixels vs percentages

What are the use cases for defining distances in a web layout for pixels and percentages?
Is there any downside to using pixels with respect to multiple resolutions? Will they scale correctly?
Percentage layout
This is generally referred to as fluid layout. Your elements will take a defined percentage of the total space available to them. This available space is determined by the element's parent.
When using percentage layouts, it's a good idea to specify a min-width and max-width on your design so that it remains usable at very low and high resolutions.
Pros
Scales with screen size, therefore get to use more space if it's available.
Cons
Makes it more difficult to know the exact position of something on screen. As a result, it can make creating precise layouts more difficult.
Can lead to unexpected layouts if child elements are fixed width (i.e. an image) and end up being larger than their fluid width parent.
Pixel layout
This is usually known as fixed layout. Your element will always be the same defined pixel size and will not take available parent space into account.
Pros
Always know an element's exact size.
Creating precise layout is easier.
Cons
You don't scale with resolutions. Your layout will always be the same width, making for wasted space when people have high resolutions.
I'll reply to this one by telling you a true story.
We had a client which wanted a map view, made up of divs.
Suddenly, he decided he wanted zooming as well.
I had to change all those fine-grained pixel positions to percentages.
Causing the wrapping div to change width/height (in pixels) relatively, we got a nice and reasonable zooming effect.
NB: During design phase, I quickly drew up a prototype, I'm going to look it up for you...
Edit: Nope, nothing found, sorry.
For percentages you have to have a base value, so it would be something like an image that has a size set outside of the CSS, if you just use a percentage on a DIV, for example, it wouldn't have anything to base that off of except the actual size it was by its being filled with text, for example, so it would not be practical to use percentages as a way to size it as it would rarely produce the desired output, if you are re-sizing something with a pixel size, such as by using javascript, you could resize by a percentage that would resize the original value (in pixels)
They do different things.
Pixel values always relate to hypothetical pixels on the output device.
Percent values relate to the computed size of the containing block (for block elements) or the containing block's font size (for font sizes).
Em and pt values relate to the current font size.
If you want your item to scale with its container, use percentages. If you want it to scale with font size, use ems. If you don't want it to scale at all, use pixels.
And then there's IE6; whoever 'implemented' CSS in that thing obviously had no idea what the various CSS properties were supposed to do.
Be careful using percentages, webkit browsers don't calculate percentages correctly. It's all because webkit doesn't calculate subpixels correct.
Detailed information about this issue can be read here: Percentage bugs in webkit
I would recommend you to always use pixels to don't have any layout dimensions differences between browsers.

A bit of tiling

I just finished writing a small script to combine a lot of png pictures into
a bigger one for CSS Sprite.
So basically, I have a list of dimensions [(w1,h2), ..., (wn,hn)]
and I need to put them into a frame with dimension (W,H) with WH as
small as possible. (Of course they cannot overlap)
The heuristic I used is obviously not optimal. I was wondering
if you had any ideas on the subject?
Do you think some smarter constraint, like grouping images with
similar histograms would make the png smaller?
It is not obvious from how you pose the question whether it is the dimensions of the picture, or the size of the PNG file, which you want to optimize, as picture histograms do not affect their dimensions (width and height).
However, finding minimal K so that, say, max(W, H) < K, so that all your pictures can be fit into a rectangular area W wide and H tall is an NP-complete problem, which means that it is difficult to solve well in general. See for example here.
How does the output from your script compare to the output from ImageMagick?
About making the resulting png smaller:
Be sure to use best compression level (level 9) and if possible, use PNGOUT to compress the PNG even better (there's a PNGOUT plugin for IrfanView, too).
Grouping images with similar histograms could be good, note that PNG uses zLib which uses a sliding window, so it work best if you group the images horizontal.
EDIT: Same for free space. It should be better to have free space at the top or the bottom of the image than at the left or right. The color of the free space shouldn't really matter, some color or black or white should be fine.
By the way, the size of the zLib sliding window is 32K, so it's not that good for detecting image duplicates if images are big. You'd better process the images yourself with an own algorithm in this case and use some duplicate removal or delta filter.

Resources