Simple maths on image height

It has taken me a while to post new stuff, but since I finally got around to it, I'll post it anyway.

This time, the description of the problem is not in the lede, but hidden somewhere in this post.
I know there may be a much simpler way and I might have even thought about it after creating this post, but the following is just a way to express how I got to it. My best excuse is that I wanted quite a lot of precision and I found the following to be the best way.

Recently I got my hands on a very simple GPRS feature with only a WAP browser as its most advanced feature. It has 600 kilobytes of storage for small sounds and images, and I'd learned to use the WAP browser to download previously down-scaled photos as background pictures to customize the phone.

One problem that I ran into, is that the phone's default main screen UI text showing operator, date and time is in white colour, and this interferes with images that have white elements of it.

At that time I hadn't found out yet that I could customize UI text colour as well as add text shadows. The limited selection of colours, and text shadows made things legible, but not nice-looking, so I decided on keeping the white text.

Usually, this means that I'd only have to choose pictures with coloration that avoid the white colour. But recently I photographed a very beautiful event, and I wanted the phone to contain a picture of it, but in a way that much of the event would stay under UI text, with the sky above the event serving the function of a beautiful background to white text.

The final photo had to have the dimensions of 128x97 pixels (width x height) without the loss of aspect ratio.

I had previously created myself an XCF template image of that size in GIMP to be able to test the background image against the precise UI simulation before using mobile data charges to download the final and best version.

The precision was based on a "screen measure" image I'd saved in the phone to measure how many pixels the main screen text used up height-wise and how much of the background was free.

Out of a height of 97 pixels I measured 46 pixels that are used up by main screen UI text.

This is what I did in GIMP:

• In the original large photo, I chose a baseline from the bottom of the selection from which I wanted to expand the selection upwards. The baseline was the lowest point from which I wanted to include information in the selection that would make it to the final image, small as it would be;
• Then I cropped away the parts below the baseline and kept the rest of the photo. That way it was easier to select from the bottom.
• After that, I raised the selection, but discovered a roadblock, because I didn't know how high I should raise it: I wanted the event to stay more or less just below main screen text, but in such a way that the text and the top of the stage wouldn't touch.
  
  The trouble, of course, was getting the height right. I kinda knew that trying to get it right 'by hand' just by making a selection and then testing to see how it looks would take too much time.

I knew I had the base information: 97 pixels height, 46 pixels reserved height at the top which I couldn't use, and 51 pixels that I had free.

Yes, I could have just downsized the big image with Shift+T and a 128x97-pixel layer above it to try and get the approximate right size, but that's not enough for a small image that has to be pixel-perfect.

I realized that it should be possible to get to the right height from the selection that encompassed the area that I wanted to stay below main screen text. This became the essential question.

(I didn't really need the width, because I'd use the template image to calculate the width of the selection using the Scale image widget by just inputting the desired height, given that 128x97 were already set as base dimensions.)

I do admit not being very proficient in mathematics. So I found a simple-to-understand online percent calculator and the default operating system calculator. After much trial and error (but hey :-) I got the right calculations and put them in the right order. Then to automate the whole thing so as to spend less time in the future, I proceeded to put these calculations into LibreOffice (I had to separately find out how to do percent calculations there), and eventually got to connect individual calculations into several formulae.

Yes, I am sure there are probably much simpler math formulae for these calculations, but the main one along with adjacent ones works as expected.

Then I turned to Google Docs, which is this awesome thing if you want to share interesting documents with the world,^* and made the spreadsheet look nicer for embedding in a blog.

* Note that information that people want to keep private, secure, and in a cloud, should be kept with the companies that meet three criteria: that said companies are headquartered in countries that have strong respect for people's privacy, that the clouds they use are also located in those countries, and that said companies do not have operations in countries that do not respect people's privacy.

So here's the embedded document, and a link to it:
Calculating reserved image height from a selection

So, in the blue column 47 pixels from top of the image is reserved height; if I change it to 46, the other figures will change accordingly. The 'Input free height' cell is where I set the height of the selection that must include everything I want below main screen text; 'Total' is the total height of the selection.

After I get the total height, I use the 128x97-px template image in another window and the Scale image tool where I replace 97 px with the total height, move input focus with the tab button, and the Scale image tool will calculate the right width for me (if height and width values are connected, as in keeping the aspect ratio).

Then I changed the selection in the big image to that size, moved the selection around a bit, copied it, pasted as a new image, and then scaled the image down to 128x97 px. In the scale image tool, I only needed to change the height from 698 pixels to 97 pixels; the width — as the aspect ratio was correct — was then calculated to 128 pixels.

All in all, I had only four tries and not more. That last two consisted of moving the selection around in the big image to more or less center the stage that I had photographed. The right image turned out to be the one at the third try, when I compared the third and fourth tests.

Maybe in the future I'll provide example images to make a visual point of what I wanted to achieve.

Designing content for mobile phones

This one is a short one.

Now, every once in a while a developer has to test their content with a device that is not very widespread, but which form factor is. These are typically mobile phones that are older or just basic. No, not everyone has a smartphone; This may be because of circumstance, or necessity, or for just being a holdover who wants to avoid planned obsolescence on their device. There are millions of these devices in use and there's always a chance someone uses them.

Content in this case is not just a web page or a wap page, but also a background image, which has to fit the screen; or an image in a mobile web page which shouldn't be too large for a screen. So, a background image, which I'd want to fit right across the screen of a phone.

Yes, there are many web pages listing resolutions for numerous device models, and I've even seen several sites that attempt real-life representations of how a mobile phone would appear and look like without necessarily having to buy it, but that's not quite it, because the data is represented in the most convoluted manner, no matter how basic or fancy.

So the solution is this very nice collection of screen resolutions at
http://lab.artlung.com/screen-resolutions
— with corresponding phone models writ inside. These start progressively from the smallest ones at the top to the biggest near the bottom. Each screen resolution is formatted in its own block to the pixel size of what a corresponding device would have, and colour coded progressively from gray to red to indicate how many models each resolution is represented by. Most of all, its very, very simple and intuitive.

This is what I or a developer/content creator really would like to know, because this helps to determine either exact or, as required, the most approximate size of generated content. Often-times browser/user agent statistics don't always reflect the size of a customer's screen, so it's important to know what they are using and how they are seeing the resource that the customers are visiting.

Netiquette: Large images and the Internet

In July 2008, a family member far away wrote me that she had been having trouble sending images to people. So here's an article that I initially wrote for her, but decided to re-edit and publish it in here for all to read. She sent me four very large photos.

Netiquette

The photos in their original photographed size are very large, which is why most Internet service providers intentionally impose technical limitations in their e-mail servers on the size of e-mail that can be transferred. The original large size of the photos is useful for when there's a need make high-quality prints (even above the 3x4" or 10x15 cm range).

When view digital photos in a new computer, then it is powerful enough to be able to temporarily resize them to the proper viewing size every time they are opened for viewing. This functionality may create an illusion that the images are not as large as they really are.

An important part of the netiquette in e-mail is to send messages that have reasonable sizes, so as not to constrain all the server computers and network traffic routers through which e-mail passes through. All servers have restrictions as to how large an outgoing message can be. A user's outgoing server may have lax restrictions, the addressee server may not.

Photos that people send to others are usually very likely to appear in a message in-line, when that message is being viewed in an e-mail folder. Some e-mail programs allow automatic resizing of images, so they equally create an appearance of a size that fits.

One solution is to send large photos on a piecemeal basis, especially if there is an actual requirement to send large images.

One way to know how much a sender can send at a time is to see the error message of a returned letter. Somewhere down there must be an error message stating the permitted space limit. Note that addressees' servers' limits on the size of incoming messages always differ. Pass-through mail servers may also have their internal space limits.

Another solution to sending images is to compress them into one .zip file, for example. In Windows XP and Vista, there is a built-in compression program with functionality to select a bunch of photos, then click on the selection with the right mouse button and select "Send To" > "Compressed (zipped) Folder".

Oftentimes (and even then) the collections of photos even in a compressed file may end up too large. Compression of files also takes time, so if there are lots of large files, compressing and uncompressing them takes some time.

Resizing/scaling images

Yet another solution is to resize all images to something the expected size of people's screen resolutions. For example, the four photos I received this February were each more than two megabytes in size and that is really huge. Even individual images are large. One way to reduce their size is to scale them down with a good image processing program.

For example, a particular group pose photo I received is 3264x2448 pixels in size (width x height). This would probably fit a large wide-screen monitor or be proper for an equally capable projector. Most people's computer screens are nowadays set to 1024x768 pixels.

When opting to send a fair number of not-so-small photos through online means, then, yes, it is a really good practice to resize them.

My favourite tool for this is The GIMP &nmdash; The GNU Image Manipulation Program (GNU is a recursive acronym for GNU's not UNIX). The latest release is 2.6.2 and it contains many improvements over the 2.4.x [development] branch, the major version that I had been thinking of mentioning when writing this instruction set long before the 2.6 version suddenly came out.

The GIMP is available from gimp.org

If there are many images...
For batch processing, there is a plugin for GIMP called DBP — or David's Batch Processor. DBP is available from here. (Download link on the left side of the page.)

Extract the executable (an application) into this directory (it's better if GIMP is not running at that time):
C:\Program Files\GIMP-2.0\lib\gimp\2.0\plug-ins
Run GIMP after that and the extension is under the Filters menu as a "Batch process..." command. Note that the extension also launches a command-line window. It can be minimized.

The user interface of the Batch process plugin is more or less straight-forward.

• When adding images, choose those that are similar in their features — for example that the width of every image should be longer and height shorter: the batch processor will otherwise make a portrait-positioned image out of landscape-shaped images ugly. The resultant image can later be turned to the suitable portrait/landscape position.


• Under Resize tab, enable the Resize function.
  If the image size is 3264x2448, then it is important to first test through an individual scale process to see what the results are. Choose Scale from the Image menu.
  For example, scale the image to resize it to a 1024 pixel width (the height is calculated automatically). The result should be 1024x768, if the aspect ratio is 4:3 (or 3:4), if memory serves me right.
  The reason for this is that while the DBP plugin's resize function allows relative resizing whilst keeping the aspect ratio, it's impossible to tell what the resultant width in pixels would be.
  That is why I choose absolute resizing, knowing that the aspect ratio will be maintained, if I set the absolute width and height to 1024x768 pixels — if a 3264x2448-pixel image scales to 768-pixel height if the width is previously set to 1024 pixels.


• The Rename tab's functions allow choosing a different destination directory and in the Output tab a relevant image format must be specified — JPG for photos and PNG for non-photographic material (pictures, screenshots, drawings, etc.). After setting JPG as the output format, the image quality must be set to 100 (the output will still be considerably smaller, even with a 100% image quality). Other things can be left as default.

Optical Disc authoring

One way of physically sending a large batch of photos is to buy a quality optical disc (typically one with gold as the default/main metal of use; Some products are geared/optimized toward a certain task, such as audio burning, data, photos, etc.), such as a CD-R (Recordable) or CD-RW (Rewritable) from a known brand with a history of producing writeable media (EMTEC, Verbatim, TDK, Philips, Sony, Maxell) — and burn the photos there.

For more size, a recordable DVD presents a good option. There are several recordable DVD formats, but it's best to choose the format that the optical disc writer at hand supports. Both CD's and DVD's come in various sizes, so if there's only up to 200 megabytes of photos to burn, an equally fitting pocket-sized CD is the ideal option — only that it may cost less than a vanilla 650–700 Mb CD-R. Standard-issue CD-R-s can store from 650 to 700 megabytes, depending on specification.

Rewritable optical discs (marked with XXX-RW or XXX+RW) are useful for testing. When I last burned data, I discovered a rewritable CD was very useful, because of a program setting I forgot to set in K3b, an optical disc authoring program in Linux, and so several burning sessions were lost and this allowed me to make mistakes. Rewritable optical discs have lesser storage latency, though, compared to one to which data is written to permanently.

On the other hand, rewritable discs are great for short-term projects, such as when using a backup application for the first time or trying out another program for disc authoring.

In addition to selecting a quality disc, the packaging also shows the suggested recording speed or a range of speeds. I've seen TDK's CD-s' packaging with the specification of "Up to 52x" writing speed. The great thing about it is that such language is not ambiguous.

Some writeable CD's have specified 4–16x writing speed. While 52x writing speed may be fast and may save time, it may not be useful for long-time storage of data, as error correction information is not saved because of such a speed of writing, so choosing the slowest possible speed is best for long-term storage, provided that the disc is equally suited for it.

Optical discs are also sensitive to elements, so that combining all the best practices reduces the chances of data loss. Some good disc manufacturers already produce optical media that have protection against elements, such as ultra-violet light and scratching. They are more expensive and usually geared toward heavy-duty use, but are all the more durable.

Once a burn is complete, it's important to use a marker specially labelled to be used on optical discs (CDs and the like).

More in a Wikipedia article about CD-R's, with plenty of essential advice on authoring an optical disc. The right-hand sidebar also shows links to other formats, just that CD-R is one of the cheapest ways to store data longer-term off a hard drive /my own long-term experience has shown that hard drives may eventually fail.