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.
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.