Gfxile – Graphicsile Collective publishing aggregator

Indeterminate progress is not progress

This post is from Undocumented stuff. For commenting, click on the title.

The progress paradigm

Before, you could open your computer, do your stuff, close it and enjoy life. Remember when loading a program, like a word processor, took a minute or more?

Today’s applications and websites typically employ a model where there’s a backend process that either runs locally on the same machine or on a server somewhere. Computers are thousands of times faster and perform much more analogue-like and complex functions.

Here’s the problem – we spend hours of our day staring at this:

It spins. It spins and spins to no end. We don’t know how long it’s going to spin. That’s why it is called an “indeterminate progress” indicator. And the program that shows you the spinner doesn’t know how long it will spin. In some cases, it might not even know if it’s ever going to stop spinning. You could leave it and come back the following day and still find it spinning.

The indeterminate progress indicator serves and important function. It tells you something is happening and there is nothing you can do about it. It is like the wheels of bureaucracy brought into the computer world. “File these applications and wait for a response.”

Better times

Those times when we waited for the program to load from a floppy were better in many ways:

• You knew that the program always would load
• You knew approximately how long it would take
• You had an indication on exactly what is happening – the floppy drive made a distinct sound that let you know that data was being read from the disk! You probably could even know what condition the floppy was in and when it was time to make a new usable copy of it.

Why can’t we still do this? Why must we look at a quiet spinner that tells us nothing? In some cases, it might momentarily stop spinning, making us hold our breath until it starts spinning again. Imagine seeing it while rebooting your portable device – and it stops for 20 seconds!

Informative Progress Indicator

Indeterminate progress UI components should allow for the program to provide feedback. Perhaps mechanical sound is no longer the way to go, although that would be cool too, but at least some sort of visual feedback. This could be called an Informative Progress Indicator.

There’s a lot happening during that spin.

• Web app refresh: there’s a lot of information going to the server and returning from the server.
• Standalone app spinners: the app knows, even if the task is being run in a separate thread, when something is happening and when not

If the spin involves sending a request to a server and waiting for a response, why can’t the server talk back small bits of information while it is processing? Let’s take a typical case of sending a REST-type request to a server.

Send request as POST or GET -> wait, wait, wait -> receive a monolithic XML or JSON response.

This could be:

Send a request as POST or GET -> start receiving a text stream from the server -> receive a “START PROGRESS” line if the server supports this, then receive “ticks” for random processing, followed by a line feed each. They could be:

• Empty line changes whenever nothing quantifiable is happening
• A floating percentage value when the server knows how much is already processed
• Other numeric value when there is something quantifiable but not a known fraction of the completion
• When all is done, a line signifying that the actual response is coming, e.g. “END PROGRESS”

Then, receive the JSON or XML you normally would get.

Now you have all sorts of information at your disposal.

Imagine opening Mac App Store and actually seeing it communicate with the server, giving you assurance that eventually something will happen?

A non-artist rendering

Indeterminate progress is not progress

This post is from Undocumented stuff. For commenting, click on the title.

The progress paradigm

Before, you could open your computer, do your stuff, close it and enjoy life. Remember when loading a program, like a word processor, took a minute or more?

Today’s applications and websites typically employ a model where there’s a backend process that either runs locally on the same machine or on a server somewhere. Computers are thousands of times faster and perform much more analogue-like and complex functions.

Here’s the problem – we spend hours of our day staring at this:

It spins. It spins and spins to no end. We don’t know how long it’s going to spin. That’s why it is called an “indeterminate progress” indicator. And the program that shows you the spinner doesn’t know how long it will spin. In some cases, it might not even know if it’s ever going to stop spinning. You could leave it and come back the following day and still find it spinning.

The indeterminate progress indicator serves and important function. It tells you something is happening and there is nothing you can do about it. It is like the wheels of bureaucracy brought into the computer world. “File these applications and wait for a response.”

Better times

Those times when we waited for the program to load from a floppy were better in many ways:

• You knew that the program always would load
• You knew approximately how long it would take
• You had an indication on exactly what is happening – the floppy drive made a distinct sound that let you know that data was being read from the disk! You probably could even know what condition the floppy was in and when it was time to make a new usable copy of it.

Why can’t we still do this? Why must we look at a quiet spinner that tells us nothing? In some cases, it might momentarily stop spinning, making us hold our breath until it starts spinning again. Imagine seeing it while rebooting your portable device – and it stops for 20 seconds!

Informative Progress Indicator

Indeterminate progress UI components should allow for the program to provide feedback. Perhaps mechanical sound is no longer the way to go, although that would be cool too, but at least some sort of visual feedback. This could be called an Informative Progress Indicator.

There’s a lot happening during that spin.

• Web app refresh: there’s a lot of information going to the server and returning from the server.
• Standalone app spinners: the app knows, even if the task is being run in a separate thread, when something is happening and when not

If the spin involves sending a request to a server and waiting for a response, why can’t the server talk back small bits of information while it is processing? Let’s take a typical case of sending a REST-type request to a server.

Send request as POST or GET -> wait, wait, wait -> receive a monolithic XML or JSON response.

This could be:

Send a request as POST or GET -> start receiving a text stream from the server -> receive a “START PROGRESS” line if the server supports this, then receive “ticks” for random processing, followed by a line feed each. They could be:

• Empty line changes whenever nothing quantifiable is happening
• A floating percentage value when the server knows how much is already processed
• Other numeric value when there is something quantifiable but not a known fraction of the completion
• When all is done, a line signifying that the actual response is coming, e.g. “END PROGRESS”

Then, receive the JSON or XML you normally would get.

Now you have all sorts of information at your disposal.

Imagine opening Mac App Store and actually seeing it communicate with the server, giving you assurance that eventually something will happen?

A non-artist rendering

0xdec4c8

This post is from Undocumented stuff. For commenting, click on the title.

Putting together some simple 3d for fun once again.

Made a little cube, put the vertices and indices together, made a couple of array buffers and rendered a cube.

Now usually to make a cube, you’ll need at least 8 vertices and index lists for the triangles or quads for the six sides. A triangle list seemed suitable, so that makes 12 triangles, 36 indices. So here’s the two lists:

GLshort cubeverts[24] = {
    -10, -10, -10,
    10, -10, -10,
    10, 10, -10,
    -10, 10, -10,
    -10, -10, 10,
    10, -10, 10,
    10, 10, 10,
    -10, 10, 10
};

GLushort cubeinds[36] = {
    0, 3, 2, 0, 2, 1,
    1, 2, 6, 1, 6, 5,
    4, 5, 6, 4, 6, 7,
    0, 4, 7, 0, 7, 3,
    7, 6, 2, 7, 2, 3,
    0, 1, 5, 0, 5, 4
};

The 8 vertices need in total 24 values, 3 coordinates for each corner. Now if the only thing you really need to know is if a value is positive or negative, that sounds like a bit. Just looking at the values, are they positive or negative, here’s a list of the corresponding polarities:

- - - + - - + +
- - + - - - + +
- + + + + - + +

See how they are conveniently in groups of eight? Reading the bit values with MSB on the left, the three 8-bit values are C8, C4 and DE. Ordered in a single integer, little-endian, that is 0xdec4c8.

Therefore:

GLshort cubeverts[24];
for(int i=0;i<24;i++) cubeverts[i]=((0xdec4c8 & (1 << i))?1:-1);

For the indices, there’s gotta be a way to compress them down too, keeping in mind the CCW/CW order of faces for triangle lists. Maybe later…

Hungarian Notation

This post is from Undocumented stuff. For commenting, click on the title.

Years ago, I got a task to add features to the source code of an existing application. It originated in a company that was seemingly obsessed with win32-style programming and Hungarian notation.

After a while, the m_lpsz, g_u32 and s_aul prefixes started to make sense, and almost immediately after that, they stopped making sense.

Here’s what some say about Hungarian notation:

• Bjarne Stroustroup: “is completely unsuitable for a language that supports generic programming and object-oriented programming”
• Linus Torvalds: “Encoding the type of a function into the name is brain damaged”
• Microsoft .NET naming conventions: “DO NOT use Hungarian notation.”

The fact is, the times when it had a function are long gone. The purpose of it was to be informative about the variable or function type. It was supposed to be helpful, so that when you needed to change the variable type, you had to go through all instances where it has been used and skim through the code to make sure it still performs its intended function with the new type.

Today, showing the variable type is the responsibility of the IDE. When you mouseover on a variable (or even as you type it in), a decent IDE already tells you what the variable type is or what is the return type of a function. And when you change the name of a variable, even if it’s Hungarian, what you’ll probably do is a project-wide search and replace.

The person who originally came up with it at Xerox, moved on to work at Microsoft, and they later abandoned its use. Nowadays it still seems to resurface here and there. I seriously hope no one’s teaching it.

When it comes to readability, which one is easier to read (an actual example, for some reason, this company did not believe in vowels):

BYTE **alpszInpts(BYTE *p_lpszTStrDvcNm)
or
vector<string> listInputs(string deviceName)

There’s still one thing that it’s very well suited for: IOCCC

Poor man’s photo backup, part I

This post is from Undocumented stuff. For commenting, click on the title.

A photo library, around 100 000 photos, not really professional but nice-to-have photos. Some of them are blurry, unfocused, or just plain horrible photographs. No time to browse through everything and only keep the really good ones. Aging hard drives and you badly need a backup, but 300 GB is just too expensive to store in the cloud. Sound familiar?

What you need now is an insane compression ratio.

Now, how can you drop the file size by a factor of 10 or 20? Can you compress those images down to be tolerable but not super-high quality, since the goal here is just to back them up for the worst-case scenario?

How about storing them in a video file, one per folder, one frame per second so that you can still browse through them when needed? This is an experiment that I’ll be documenting as it goes on. Might be a terrible idea, but who knows?

To do this, the following steps are needed in each folder (all of this should work on OSX or Linux):

Downscale the photos to fit inside a n * n box (letterboxes). This will allow both horizontal and vertical photos to retain their relative quality. ImageMagick does this nicely.
The following line does this, if your input file is “file.jpg”.

convert file.jpg -filter cubic -resize 2048x2048\> -gravity center \
  -background black -extent 2048x2048 out.jpg

Convert all these files into a mjpeg stream, so that it can be fed to a video encoder.

convert file.jpg -filter cubic -resize 2048x2048\> -gravity center \
  -background black -extent 2048x2048 jpeg:- >>all.mjpeg

Do this in a loop for all the photos in a single folder:

for a in `ls | grep -i "\.jpg"`; do
convert "$a" -filter cubic -resize 2048x2048\> -gravity center \
  -background black -extent 2048x2048 jpeg:- >>all.mjpeg
done

Now there’s a huge file, all.mjpeg, that has all those photos letterboxed with a black background, as a continuous sequence. This, of course, can easily be fed to ffmpeg:

ffmpeg -vcodec mjpeg -r 1 -i all.mjpeg -s 2048x2048 \
  -vcodec prores_ks -y out.mov

My input images were around 300 MB, the intermediate mjpeg file was 80 MB, and this gives me a prores video file at around 60 MB. The output video file looks really sharp and there’s barely any loss of quality. We could have some loss of quality.

ffmpeg -vcodec mjpeg -r 1 -i all.mjpeg -s 2048x2048 \
  -vcodec prores_ks -y -qscale 16 out.mov

This drops the forced quality in prores by a factor of 16. Some blockiness will appear in subtle gradients and blurry regions of a photo, but that is completely fine. Result: 19 MB. That is, a compression ratio of 15:1.

This would bring 300 GB of data down to 20 GB. That’s something that already can be stored on a USB thumb drive. Or on a slightly larger free could account. Acceptable.

Now, what about all the metadata?

As we’re dealing with photos, it’s got to be exiftool. It can output an XML with all the metadata included. Now, to do all of this in a simple loop and end up with a .MOV and .XML file, I wrote the following shell script, called “photorescue”:

#!/bin/bash
pwd=`pwd`
thisdir=`basename $pwd`
for a in `ls | grep -i "\.jpg"`; do
  echo $a...
  convert "$a" -filter cubic -resize $1\> -gravity center \
    -background black -extent $1 jpeg:- >>all.mjpeg
  exiftool -X $a >>"$thisdir.xml"
done
ffmpeg -vcodec mjpeg -r 1 -i all.mjpeg -s $1 -vcodec prores_ks \
  -qscale 16 -y "$thisdir.mov"
rm all.mjpeg

This tool will handle all the .jpg (and .JPG for that matter) files in the current folder and output two files:

photorescue 2048

Where 2048 is the resolution you want to use. A folder can in this way be classified as “I really want to keep these in higher res” or “I don’t care about these photos but whatever”, using higher and lower values as needed. Using a really low value will make a thumbnail video.

Other things to try:

- Use a non-keyframe-only video codec to deal with folders with lots of similar photos and automatic scene change detection to bring the compression ratio even higher.
- Write out the actual rectangles and timestamps where the image ended up into the XML metadata

Create ringtones from YouTube

This post is from Undocumented stuff. For commenting, click on the title.

Most of the methods online for creating ringtones from YouTube seem to involve shady websites with ads and registering accounts, if they even happen to work. So here’s a simple workflow for choosing what you want and creating a ringtone in a matter of minutes.

All of this assumes you have a Mac, if you don’t, go the shady website route. Just be careful with your credit card details.

You’ll need a couple of tools:
Clipgrab - for downloading the video from YouTube
Speaktone - for converting text or any media file to a ringtone

1. Choose your video. You probably have this part sorted out already, otherwise you wouldn’t be googling for this stuff. In any case, copy the video URL to clipboard (⌘-C).

2. Run Clipgrab and paste (⌘-V) the URL to the field in the Download tab. Click on “Grab this clip!”.

3. Wait for the download to finish and double click on the downloaded file. If this opens some other player than Quicktime, close it and browse to the file instead. Right click on it and choose “Open With / QuickTime Player”. You’ll be presented with the clip in QuickTime Player.

4. Now, choose Trim from the Edit menu, or hit ⌘-T. This will change the playback bar into a trim control, with which you can choose the span of video you want to make your ringtone from. Adjust the start and end controls.

5. Hit Save (⌘-S). This usually pops up a save dialog since it won’t want to override the original file, so give it a name.

6. Open Speaktone. Drag the newly created file from Finder into the box in the bottom of the Speaktone window.

7. This brings the created ringtone to iTunes. If you’ve set up iTunes to automatically synchronize ringtones to your device, this is all you need to do. If you’ve set that to be manually managed, you’ll still need to drag and drop the ringtone within iTunes into your device.

Streaming basics

This post is from Undocumented stuff. For commenting, click on the title.

As a quick crash course on video and audio streaming, here’s some nice facts and articles.

The tool of the trade is RTSP, like it or not. There are methods of streaming through HTTP, but to make something that supports multiple streams or any sort of negotiation, it’ll always come back to RTSP.
RFC 2326 - Real Time Streaming Protocol

Now, in order to encapsulate content and provide it through RTSP, there’s RTP. Yes, the acronyms are very confusing. But remember that RTSP and RTP go hand in hand for most cases.
RFC 3550 – Real-time Transport Protocol

RTP encapsulates any stream protocol that is for the actual media. MPEG-4 streams have their own, H.264 streams their own.
RFC 3016 – RTP payload for MPEG-4 Audio/Visual streams
RFC 3984 - RTP payload for H.264 Video

Now, you can use these RFC documents to make your own RTSP/RTP server or client. Or you can use one of the available libraries.

Libavcodec – can decode most payloads. Note, this is not to be used with the RTP packets themselves.
Libavformat – can handle connections to RTSP servers and read RTP packets and provide the payloads contained. Also it can provide a decodable frame for libavcodec.
Live555 – can handle RTSP connections and read RTP packets.
VLC – uses libavcodec and libavformat for most functions but the source code still provides a lot of insight into handling streams.

Two photos

This post is from peeba.gfxile.net. For commenting, click on the title.

Just a quickie post with two photos from last weekend.

Unity version of MonoDevelop on OSX won’t run

This post is from Undocumented stuff. For commenting, click on the title.

…that is, if you are not running your system as admin. MonoDevelop assumes that everyone who uses OSX use it as admin.

The way to fix this is to give you rights to the folder it wants to install its Mono library stuff into:
/Applications/Unity/MonoDevelop.app/Contents/Frameworks/Mono.framework

Give your user write permissions to that folder (and anything in it), using posix permissions or ACLs. Then it works.

Some more music

This post is from Undocumented stuff. For commenting, click on the title.

Here’s one old track remastered and another new piece:

Cabo Blanco (2012 remaster):
Cabo Blanco (2012 remaster)

Detective Story:
Detective Story