free software » The Blog From Hell

I need a time-out.

Oct 212009

We are, rapidly, approaching the one-year anniversary of my initial announcement that I am starting the kongoni project. Today, I can look back at that year as an achievement, what was a vision has been realized into a released project with a solid and growing userbase. We’ve had an amazing hackfest where a lot of the core work toward our next release was done – and that was great.

However, 2.13.0 is going to be a little later than expected, in fact I won’t promise anything before early in 2010. The reason is very simple – right now, I can’t work on it, there are other people working on their parts, but the big “put-it-all-together” task is going to have to be postponed. I have at the same time during this year gone through terrible emotional events. A divorce was just the start, and it’s been building up.
Right now, I’m clinically depressed, I have very little energy and my sleeping patterns have gone straight to hell, what energy I have needs to go into my dayjob – to keep the bills paid. I feel no shame about saying: my limits right now are reduced, I cannot perform at my usual level and I need to cut down a bit.
I need to get home, eat a healthy meal and go to bed at a reasonable hour. I need to focus on dealing with practical matters-of-life on a one-at-a-time basis, solving them and preventing them getting out of hand, and I need to take care of myself a bit.

I have been through depression before, I know my way out, this is not a permanent thing, nor is it regular, in fact I haven’t had full-on depression like this in nearly 5 years, my normal techniques for preventing it… well they just couldn’t keep up with the sheer amount of things to deal with in the last few weeks.

So, though it saddens me, I have to say – a fundamental reason why kongoni is not only non-proprietory but crucially non-commercial is this: I don’t do deadlines. Kongoni was set up this way, so that if somebody needs a time-out they can take it, so that it will always be fun – never work.
Right now, it’s not fun, because I simply don’t have the strength. In a few weeks or months, this will change – and I’ll be my old self, of this I’m fairly certain – in the meantime, I ask you to bear with my. My fellow coders, keep up on your side, if you think you can handle some of mine, please do ask – I’ll try to help you get started. To the users, I know you’re all anxiously waiting for Cicero, and it will come, I will be back in the saddle as soon as I can.

But I don’t want to give you a rushed half-job, I want to give you the best next version I can – and that requires me to be the best I can be, and right now, I’m not.

So, for medical and personal reasons – I am taking a time-out from kongoni, for at least the next month or two. I will see where I stand in December and update you on when I expect to resume it (or perhaps that I already have).

Share|

Kongoni Newsletter: 20090912

Diary 1 Response »

Sep 122009

It’s been quite a ride starting the work on Kongoni 2.13.0 and this is our first newsletter detailing what has been happening.

The first important bit is that the votes are in, and the alpha release has been named. The first alpha of Kongoni 2.13.0 will be called: Cicero, named after the great Roman philosopher who gave us the quote “All generalizations are false”. Other proposals had included Kant, but as one developer put it “there is just no way I can say that guy’s name with a straight face”. The reasons for this comment is left as an excercise for the reader.

Of course, Nietzsche is not dead with the work on Cicero starting, updates and expansion continue. This week saw updates to our versions of digikam, KDE and icecat. New ports in the tree include UFRaw, Rawstudio and gsynaptics to name just a few. While Nietzsche will be aging from now on as it’s upstream distro is effectively frozen, it remains a stable platform and we will release updates and expand it continously for as long as we can, and certainly well into the stable cycle for 2.13.0

Our work on 2.13.0 started with updates to portpkg, earlier (during Nietszche’s cycle already) portpkg was expanded (based on work from Kongoni) to include support for slackware’s new txz format as well as a number of small updates to the rest of the system – now came the time to make the portpkg in current synchronize to slackware 13. This change was quite easy on the 32-bit platform and we have already had reports of current-testers successfully running a system after synchronizing with current. The only major hiccup was a bug in the metaport for sharutils which we fixed with our own source-port for sharutils.

The 64-bit platform is trickier as there are a number of things to address. The first challenge was allowing the system to upgrade to the new FHS-compliant directory layout from slackware64 as we are moving away from bluewhite64 as upstream. To this end a new port was created known as kongoni_upgrade_prepare. This port is available in both the current and Nietszche trees, but as it changes your target platform to current, it should not be installed on Nietzsche unless that is your intention (and current is far from stable yet – particularly on 64-bit). This port will remain a core functionality in the future of Kongoni, allowing us to script any fundamental changes to the system that needs to happen prior to an upgrade.

Thus the process to upgrade from Nietzsche to current its: synchronize your ports with Nietzsche, install kongoni_upgrade_prepare, synchronize again (now you will synchronise with slackware 13 and kongoni-current) then upgrade all packages. I would like to extend a personal note of thanks to Eric Hameleers for explaining the steps this port needs to do on 64-bit.

Please note that the kongoni_current ports are, at present, broken for 64-bit – basically all of them. The upgrade_prepare port will let you synchronize to slackware-13 but this is an intermediary step we had to finish first. However, the kongoni_current ports all still use the lib and /usr/lib as directory targets and this could cause issues with running them (I believe they won’t be severe issues and most should work – but be advised that this very risky).

Our next major task will be to hack virtually all the ports in the tree to make them FHS compliant on both platforms which will resolve this issue. We are planning a hackfest sometime in the next two weeks to sit and simply work through them all – one-by-one, and fix them. This will be a face-to-face session with the developers in Cape Town and surrounds. If there is enough outside interest, we’ll extend it over IRC, if you are interested in joining in – please mail me directly and we’ll get a discussion going on location and methodologies to use. The work is quite easy (really easy in fact) there is just a lot of it.

Once that task is completed, we will proceed with our real Cicero innovation stage, this means finalizing the new version of PIG and the enhancements to the installer we are working on. At this stage I don’t want to give an estimation on when Cicero will be released, but I don’t think we’re talking many months.

Finally, some great news: the FSF has officially added Kongoni to their list of fully free GNU/Linux distributions. That means it is now publicly recognized as a fully-free system by the people who define what “fully free system” means.

Share|

A GNU/Linux Digital Darkroom Part 5: Essential GIMPage.

Diary No Responses »

Sep 072009

Hello, and welcome to this, the final part of my tutorial series on doing photoediting with GNU/Linux and free software. I say final because after this, we’re getting into the professional arena for which good books are a much better option than blogposts. What I will be covering in this is some basic photographic handling skills and how to do them in the gimp. I won’t be using channels or layers in this tutorial but everything in here remains applicacable when you use them.

A common problem for a photographer when you shoot outside a studio, is that your light and color and backgrounds are not ideal, so we’ll learn how to do some basic corrections, and how to highlight our subject against a cluttered background. Here is a picture I took at the 7thson gig, it was near the end of the show and to get it, I had to use a very high ISO level as the light was fading and I wasn’t using a flash. The price I paid was digital noise – and the background is rather cluttered.
Here you see the image, in UFRaw, with our first bit of highlighting already busy: we’re cropping out some of the wasted stuff.

I’ve not done much else in RAW on this one as the shot was really rather good, I only raised the exposure level very slightly.

Clicking on OK gives us the image in GIMP:

Our first problem is the digital noise that came from using a high ISO level, Gimp has a built-in tool to help correct this, called Despeckle (Filters|Enhance|Despeckle). UFraw also has such a tool but it offers far less control, despeckling costs you detail so you want to aim for an optimum balance to lose as little as possible and maintain a usable picture (if perhaps not a print-quality one).

This gives us a much better picture already. Now we can reduce some of the effects of despeckling by going for a softer-focussed image, for this we use one of GIMP’s most useful tools, the Gausian Blur, with a smallish radius, it just softens the focus enough to smooth out the picture without losing so much detail as to harm it – in fact, it makes it prettier.

Now we want to deal with the background, ripping it out is possible but will cost us all context, instead we just want to remove it’s eye-pulling effect while maintaining it’s presence, so it provides atmosphere rather than interference. I started by removing the drummer’s half visible head (as it contributed nothing) using the clone tool (I cover this in detail below), now for the fun part though – selecting the background outside the guitarist. Gimp offers an easy way to select complex shapes using the Path tool by clicking along the contours you can gradually select out your target.

Now we use Select|From Path to turn our path into a selection. You can also use the lasso tool for this, but only if you have a very steady hand. We will begin by reducing the coloring of the background making it effectively a semi-black-and-white image, thus reducing it’s distracting effect a great deal and making it nice for atmosphere. First we need to adjust our selection a little, we start by shrinking it until it is just inside the border of the guitarist (Select|Shrink Selection) – so we’ll have a smooth transition, then to smooth things further, we feather it (Select Feather) by about 5 pixels.

We invert the selection to select the background around the guitarist rather than the guitarist himself, we open the Hue/Saturation tool from the colors menu. and drop the saturation a good deal – this gradually reduces the coloring of the background, until we get a near black-and-white effect with just enough color to still look nice.

Below, you can see the results, already an improvement, but there’s a catch – look at the guitar cable, it’s now much brighter on the player’s leg, and thus causes a problem, luckilly the way it runs, if we remove it, it will just appear that it ran behind him – so we have an easy answer, just get rid of it.

For this we use gimp’s clone tool. Cloning lets us take one part of the image and paint over another with it, it’s a powerful tool but at it’s most basic, using a feather-edged brush of about 35-pixel diameter and the aligned mode, it lets us quickly paint out the cable using the surrounding denim.

Now all we do is another small gausian blur to remove the edges from the changes we made, and here we have our final result, it’s pretty, it’s got atmosphere and we’ve turned a bad-luck shot into a work of art.

Share|

A GNU/Linux Digital Darkroom howto: Part 4 – Basic RAW processing

Diary 5 Responses »

Sep 012009

So, with the Kruger Park pictures uploaded, I can now proceed with part four, the first item on touch-ups, focusing on RAW work. At this stage, it’s the only part I’m willing to claim any knowledge off, mostly because it’s about 95% of what I have been doing, since my first photoset were nature pictures, and I had no reason to want to make them into logos or edit them to remove spots or anything, what I wanted to achieve was to make sure my pictures represented the reality of the scene as close as possible – for this RAW work is almost everything you need.

There are three essential skills when it comes to raw work, with a large number of sub-levels which require a deep understanding, I won’t be going into those – plenty of good books cover them in detail and there is nothing GNU/Linux specific about them. What I do want to share is a basic working method I used with, I believe, considerable success for processing RAW images on GNU/Linux. I used the UFRaw plugin because I really like getting the RAW editor before the normal image editor so this document is based on that approach.

For this howto, I deliberately worked with a picture I really wanted to save as it was the only one of it’s kind I had – and hadn’t been taken well. I wanted to make out of it, the best picture I could.

Let us open a picture – from digikam, I right-click on it and say “Open with GIMP”

This picture was taken in dusky conditions with mere moments to catch the shot. The tiny bit of camera-shake I picked up I can’t do anything about and there was no time to adjust camera settings – so the picture is dark, but that much at least we can fix.

The first thing to do is change the white balance. You can do this manually by adjusting the temperature slider (the red/blue intensity levels of the pixels), and the green slider. If you know you had a good white balance when taking the picture, keep it on the “Camera WB” or if you want to use the white balance the camera had suggested set it to “Auto WB”. There is also a number of presets, which you should recognize as the same presets generally included on camera’s.

In this case, I opted for a preset, “Shaded” as it suited the shot well, and after some experimentation I found it to give by far the best result – it brought out the colors of the original shot without distorting them. I also upped the exposure slider a little bit. I almost always avoid the auto-exposure feature because frankly – I think it’s not very good, I suspect it’s better when mapped with the point-white-balance feature as you can choose which part of the image it should base it’s exposure calculations on, but I haven’t experimented much with this.

Essentially, exposure control let’s you lighten or darken an image, since you can’t change how much light was captured by the censor, this is akin to how a film photographer could make up for it a bit by leaving the photo exposed in the darkroom for longer or shorter periods of time. There are some catches though, when exposing down – there is a lot of guesswork the program has to make, since it can’t “de-light” the image, it has to guess how to shade it darker (but it’s surprisingly good at this). Exposing up is digitally a much easier process (I read this on the UFRaw website, and I won’t argue with the guy who wrote the code about what was easier) but it has it’s own catch. On photo-paper, long exposures would cause the image to become grittier (much like shooting with higher ISO values) – in your digital lab, it introduces digital-noise.

Now digital noise may or may not be a problem for you – the amount of digital noise you get for the amount of exposure is the big thing. At lower-sized views, the noise may not be visible to the naked eye at all. This is then fine if you keep the picture for web-user or post-card sized printing. A picture that you had to up the exposure by any significant degree won’t make a good A3 print, but it may yet be a nice and useful picture and could save one that was otherwise lost. In this case, I only upped it a little as the picture really wasn’t under-exposed, it was just dark.

Here is the result of my tweaks:

The next thing that you can do inside UFRaw that I use a lot is cropping, of course you can do this with gimp as well, and I often use that one, but I rather like the way UFRaw does it and I like being able to crop while doing light work as I find it is sometimes helpful to be able to ignore the light on the areas you don’t intend to keep anyway.

In this case, I don’t want to crop a lot, but like most nature pics I got quite a bit of superfluous background that doesn’t add either meaning or context to the picture and simply reduces the real-estate for the subject, I do want to at least trim that down a bit:

With all this done, we click the okay button, and the image gets passed on to Gimp, where we can do more RAW work using gimp’s extensive set of tools, including crops if we want to etc. and when done, easily and with good control, export it to a more permanent storage format like lzw-compressed tiff or dng or whatever you prefer.

UPDATE: I discovered a small but very annoying bug with using the UFRaw plugin, when using it in plugin mode, it sends the file to GIMP as clipboard data, when you then save it (regardless of what format, but lets assume you are using LZW-tiff as your post-raw archive format) – you lose the EXIF data (since the clipboard doesn’t contain it. So I suggest using UFraw standalone, edit the raw file, and then use UFRaw to save it as TIFF with the EXIF data intact, and open the TIFF file with Gimp for your touch-up work.

Share|

A GNU/Linux digital darkroom – Party 3: Photo recovery

Diary 3 Responses »

Aug 282009

As I left after my vacation, fully intent to pursue photography all out, my dad gave me some copies of programs he uses day to day (as one who works primarily on Windows). One of which is called “RescuePro” – a program Sandisk makes freely available (as in beer) with their SD cards (though many shops neglect to include the CD’s).

The purpose of this program was, he said, to be able to recover files deleted from your SD card either by accident or because of a software bug. I hadn’t had the opportunity to look into this issue and since my new camera is not yet acquired and I was just working with pix already on my hard-drive, I haven’t had a need yet. As it turns out, fortune smiled on me and in my RSS feeds this morning was a blogpost shared by Karl Fischer covering a GNU/Linux tool for the same purpose.

It seems this is a frequent need for photographers so it’s as well to be prepared and good to know that as a GNU/Linux using photographer you don’t have to miss out on anything. I know I promised a post on touch-ups but that will take some time still, in the meantime – this was a piece of evidently appropriate information that I felt deserved a post in this series.

So I would highly recommend ensuring that you have PhotoRec installed on your machine as part of setting up your digital darkroom. The post in question (which also runs through it’s use very nicely) and has all the required information is here.

Share|

A GNU/Linux digital darkroom howto – Part 2: Photo management with digikam

Diary No Responses »

Aug 262009

So, yesterday we looked at tools for manipulating and reading the RAW format images that photographers so often use. I want to start with a small update to that, Johan has let me know of another gimp plugin called gimp-dcraw which opens the RAW files directly in gimp eliminating the intermediary step you find with UFRaw. Now I am not at all sure whether I think that’s a good or a bad thing, since Gimp won’t offer the RAW modification tools you want but it may be better for some people’s workflows so I thought I should at least mention it.

Now on to today’s lesson. Last night saw me having to start the process of organizing pictures, deciding what to delete, what are “keepers” already, what needs RAW work, what should be going for touch-ups etc.the workflow I propose here is what I came up with, it may not be something you like but the generic skills in it should be usable by all.

Digikam defaults to keeping your main local store in your home directory under a subdirectory called Pictures. Within which each directory becomes and album automatically, and subdirectories form subalbums. This is actually a nice way because it means you can quite easily construct a sensible album structure from an existing folder structure.

I began by creating three new top-level albums inside this folder called “RAW”, “WEB” and “TIFF”. Raw as you can guess is for keeping the RAW imported albums as they come in from cameras. TIFF is where post-raw compressed pictures will be kept for the future, and WEB is for dumping web-exports like png or jpg.

Over time they will have almost identical subalbum structures but with radically different content, and of course, as I finish processing an album under RAW, the RAW copy will be deleted.

Currently my photo-management tasks were centered around the pictures I took in the Kruger Park recently. I took well over 500 pictures, of which most are really bad (with nature photography being as hard as it is, you get a lot of wastage). So I needed to make sense of this whole lot of pictures, get rid of the really bad ones and find a sensible way to work through what’s left for post-processing.

Digikam handled this very well. I started with tagging, renaming files to represent their content really isn’t ideal for images – for starters it would take forever, a nicely thought out tagging structure makes it so much easier to find things later. So I started by opening the KNP album, and selecting all, then I applied a new “krugerpark” tag. Digikam allows tag hierarchies, so I then started going through the list, looking at the thumbnails and selecting a bunch at a time, tagging each set of pictures appropriately.This gave me for example a set of pictures tagged: krugerpark/birds/fisheagle for example. The ability to multi-select and tag and easily select prior parts of the hierarchy was really handy and I had everything done within about an hour’s time.

Thus with the content tagging done, the next phase came. Now I cycled them in large-preview mode, one by one. I would study each picture and make an initial assessment. The ones I were simply unhappy with I tagged with “delete”. Those I could see needed some touch-ups I tagged with “touchup” and the rare few ones I consider my best shots were tagged with “keeper”. Of course some were tagged with both touch-up and keeper (meaning I think it’s a good picture but it needs a little something such as cropping). This was a much slower process as I was working one-by-one through a huge set of pictures, but still I was done in about 2 hours and I have no doubt without digikam’s brilliant interface it would have taken a lot longer.

Thus done, I went to the main menu and chose: Tools|Advanced search. I then search for pictures where a tag contains “delete”, did a select-all on the results and chose “Move to trash” from the right-click menu. In all, well over 300 pictures didn’t make the cut, leaving me with just over 200 to go. Some of those will no-doubt be deleted over the next few days, many will get touched up. Often when there were several good shots I couldn’t yet decide which was best and will be deciding this only after touch-ups are done.

Ultimately then, I will end up with a slightly smaller subset of the above that is touched-up and ready. My approach now will be I think to start going through them one-by-one again. Open with gimp, then do my raw-editing and touchups, and save the result into the KNP album under TIFF. What doesn’t make the cut here won’t even go there.

Once everything is through that process, delete the entire KNP album under RAW and get that space recovered. Though I won’t be able to do further RAW work on the TIFF’s – future touch-ups will be possible, and of course they will be very high-resolution and quality. My plan there-after is to go through and select the ones I want to publish to the website album, and the “best-of-each” that will make up the big Kruger Park photo-blog. Again I plan to use tagging, some will be tagged “web”, some of those will be tagged “blog”.

Then a simple search will once more let me select out everything with “web” tags, and batch convert them to png which will be in a KNP sub-album under WEB. All seems quite sensible to me – and I think I like this. Even if your preferred layout is different I think the approach to tag and then work will save time and help you to manage the photos effectively and easily.

Finally – the content of the web subalbum will be uploaded to a gallery on the site, and the ones with the blog tag will be filtered into the nice big post (with, of course, a link to the complete album included).

While this post did not cover all the features of digikam (there are many, many of them) it did cover the core piece of it’s functionality, managing, finding and organizing your photos, the rest really are – in my view, add-ons.

I expect it will take a few days before part 3 is published as that will be about touch-ups – something I myself am still learning, in the meantime though, I would like to offer as a reading list the book I intend to use myself for this part. Check out the following:

Gimp 2 for Photographers – Image editing with Open Source Software

Also, check out the list of books on Gimp’s own site.

A nice overview of the basics is to be found in this blogpost (and there are many others covering various things if you don’t have the budget for a set of books).

At this stage I would like ask for a bit of additional feedback on another topic. Which other GNU/Linux friendly tools than gimp have you used for photo-editing and what did you find to be the best and worst about them (this list does not need to be limited to free software only, as I’m firstly trying to get an overview). I’m particularly interested in your experiences with krita, picassa and picnic but please mention others I may not know about.

Share|

A GNU/Linux digital darkroom howto – Part 1: Raw image handling

Diary 2 Responses »

Aug 252009

As part of my forays into digital photography on a professional level – I will be trying to replicate to the highest possible degree (and exceeding where possible) the tools and equipment used by our non-free software using friends in the windows and mac worlds, particularly photoshop and it’s associated tools.

Now to do this, I will be evaluating a number of tools and seeing how they fit in as replacements. I will blog the results and the methods I use and this will lead to hopefully a series of good howtos for the beginner photographer using GNU/Linux and free software. Since I’m a beginner myself and this is a learn-as-I-need-things series it will be on a lower level than most tutorials out there, and will also act as my own reference documentation in the future.

With this intro out of the way – let us start part one, working with RAW format images.

Now first of all the question should be answered: what is a raw image and why use it ? After all, almost every digital camera shoots in jpeg format by default right ? This is true, but real photographers override this with good reason. RAW means the image gets dumped as it’s read by the camera’s censor with the maximum amount of data stored. JPEG is in fact just about the worst format for storing images in anyway as it’s a lossy-compression. You will want to save your web-published pictures into jpeg, but you will not want to work with it yourself or store your own copies this way. RAW images are also refered to as a “digital negative” as they afford you a lot of the power that film photographers had working on negatives… and then some.

But there is a catch – there is no standard on how RAW images are stored, each camera brand uses it’s own format and sometimes it even changes between models. The good news is that for GNU/Linux users there is a very good library that can read and manipulate RAW images known as libdcraw (for DigitalCamera RAW), all the tools we use for RAW work are based on dcraw. DCRaw supports a massive selection of camera formats and virtually every common one including those used by Nikon and and Canon are fully supported. DCRaw is included in most distributions, and since it’s a dependency of the other tools here, should be installed automatically if you have it.

Now the first issue with RAW images is viewing them, and viewing them in bulk. Opening them one-by-one is not a good way to go through a set and decide which to keep, before starting to edit. The good news is that the current version of digikam includes full support for dcraw and can view them easily as can KDE4′s showphoto (which is a one-by-one tool integrated with digikam as well). Digikam makes a very solid replacement for photoshop’s “bridge” program and includes a massive amount of extra features of which I haven’t explored the half.

Where it falls a bit short is the manipulation of RAW data. Adjusting light levels and such – it includes a tool to do this, as well as a batch RAW-converter (so when you’re done editing you can rapidly export say web-jpegs of all the final results) but the manipulation tools was a bit… well clunky for me. Not knowing exactly the details of all the options you can do on RAW files, I need something that lets me play quite easily with it. It is also not integrated into an image editor which makes the next stage hard – now you need to edit the RAW file, then save it as something else (like TIFF) before you can use most image editors to work on the image itself.

Well, gimp is obviously the tool of choice for image editing. It’s powerful and feature-rich and while it doesn’t work like photoshop – it can do the vast majority of what photoshop can (I am quite certain it can do everything the beginner photographer will need for some time). I suggest reading a good gimp tutorial to learn it if you don’t know it (the good news is, I do know it quite well since I’ve been using it for things like logo designs for years). Even so I will be brushing up with some new tutorials to sharpen up my skills. I just learned today for example (thanks to a blogpost that showed up in my RSS reader) that gimp can read and use photoshop brushes.

But, here’s the catch: gimp doesn’t natively support libdcraw and thus cannot work with raw images. Free software to the rescue, I found a lovely gimp plugin called UFraw which handles this in much the same way photoshop does. Opening a raw image first loads it into the UFRaw interface which is just like it’s photoshop cousin (UFRaw also has a stand-alone version) – I will be adding a port for it to kongoni today but I don’t know how well it’s take-up in other distro’s are, it’s quite easy to build if you follow the instructions on the site though.

It actually supersedes most other raw tools because it uses the single-library nature of libdcraw to gain some real power. For example it can create and use nikon curves on images taken with non-nikon cameras (whatever that means…).

So once you install it, you open a raw file in gimp and bang – here’s your raw manipulator. You do whatever adjustments you want, and click Okay… and it then exports this as pure bitmap data and you get a normal gimp window where you can proceed with your touch-up work, and save the final result in whatever format you wish.

A note on that last point. The advice from books and other photographers agree: for your own copies, once you are done with the raw, save as TIFF format. If you want to save some disk-space, use the loss-less LZW compression (which is free software by the way). This means you can always come back later and work on the touch-up level, you have a high-quality image for exporting for print or other purposes etcetera and it takes a lot less space than the RAW files do.

While jpg continues to rule the web – I prefer to export my web images in png format, it’s more powerful far less lossy (for similar compression ratios) and not encumbered by patents.

Thus we have now set up the first part of our digital darkroom, we can browse and manipulate the raw images from our cameras, and get them to a touch-up ready point. As I learn some tricks of the trade about touch-ups, I will be sharing this in part two.

Share|

Why cellphone internet is bad for Africa

Diary 11 Responses »

Aug 032009

I have said it before, but not really spelled it out in detail but I think the proliferation of cellphones as the primary method of connectivity in Africa is not, as many have proposed, a cheap and practical solution to bridging the digital divide, on the contrary, it’s a very good way to make the rift permanent.

The essential reason is simple, cellphones will never be able to compete with full size devices in terms of capability. Cellular internet remains almost entirely a one-way thing. This is part of why, when a friend recently asked a group of West African African delegates to a conference how many of then visited facebook, almost every hand went up. When asked how many of them blogged, almost none did.

The single biggest issue in the digital divide today is not getting African’s access to content – it’s getting African created content accessible. Cellphones are extremely bad for this. Sure you could record a video or a song on a phone, but the quality is always going to be second rate. You can just about use this method to get news stories out… it’s never going to work for publishing a new song.

In Europe and the USA the biggest debates going on right now is those who see the benefit of the multiway internet arguing with those who are trying to preserve old business models that simply don’t work anymore. Newspapers, software companies, film and music distribution being the worst offenders. Instead of recognizing that in world where everybody can produce high quality content – supply and demand dictates that since the supply is now nearing infinity, the price must in turn approach zero – and learning how to find new ways of generating revenue, they are trying to maintain their status quo by lobbying for ever more oppressive copyright laws.

My views on this battle is well known, but the point of my current post is that it isn’t happening in Africa. ASAMI is making a valiant effort to be bastards in South Africa but that’s the entirety of the event to reach this continent. Nobody is lobying the AU to enforce stricter copyright requirements on it’s member countries.
Why ?

Because in Africa the corporations got exactly what they want. A consumer internet. It’s too slow to share anything more meaningfull than tweets and cellphone pix on (so it isn’t a threat to the artificial scarcity model) too limited to create any competing content and too restrictive to allow any new software or ideas to grow.
It’s one way – from the companies to the users, at premium rates.

The one thing scarier than the thought of possibly losing the internet battle in the developed world (an unlikely reality no matter how hard they lobby because ultimately, the maths just don’t work) … is the thought of never even having the opportunity to fight it in Africa.

It has been said that Africa’s major economic problem is that we lack product refinement capacity, we export raw materials, and then buy them back as usable products at ten times the price. Nigeria is a prime example, the nation with the fourth largest oil reserves on the planet also has the highest petrol price on the planet.

But our internet access is even worse off… now we’re consuming, buying products – and we don’t even get to export raw materials, we’re not competing at all, we’re not even part of the market in the other direction ! Slavery didn’t end two-hundred years ago, it’s just that the slaves are now carrying their chains in their own pockets and don’t need to be shipped anywhere first.

So we don’t get to contribute to the web in any meaningful way, anybody who has tried moblogging knows that anything longer than a paragraph is likely to you hospitalized for RSI in your thumb, so we’re still entirely dependent on media companies for news. We don’t get to download music except from cellphone ringtone suppliers – at premium rates (that actually works out more expensive than the CD’s , or only barely cheaper), we don’t get to watch streaming movies and we most certainly don’t get to use the power of the internet to get our own movies and music to a wider audience.

Who cares about the size of Nigeria’s film industry ? They will never compete with Hollywood because outside of a few choice film festivals, nobody has ever even seen a Nigerian film. They aren’t in the video-rental stores, they aren’t showing at the theaters – they may as well not exist, the one technology we have that could change this, could make them have the kind of success that has seen numerous independent films from all over the world grow to massive hits online – which ultimately led to real DVD sales etc. and made them financial successes, these ideas aren’t available to us.

Now sure it was an interesting experiment when one South African film maker made a full length movie shot entirely on cellphones, but he still needed a computer to put it together, and that was a particular artistic expression, it’s hardly the appropriate method for making good quality indy films in general.

I think I’ve made my point, so as usual, I shall end with a pithy summary of this post for the tweep generation: mobile internet isn’t.

Share|

Older Entries Newer Entries