Day 15
Ok, so I let the days get away with me a bit there, so sue me. I was on holiday in the mountains. You'd've done the same.
The Kubuntu At Work project is ongoing. After the initial teething troubles were sorted out in the first few days, things have been going fairly smoothly since. There are the odd hiccups, which I'm going to blather about at length, rest assured, but overall, the project is cautiously optimistic to date. Knocking wood. Knocking all the damn wood I can get my fists near.
On getting back from my holiday, I was faced with the first major photo sorting and editing event since switching. I'd managed to pretty much fill my 1GB memory card with pixels, and offloading them onto the laptop (no mean feat – I had to go make coffee while it was chugging away) revealed I'd have my evening's work cut out for me pruning them back, touching up here and there, and selecting a bunch suitable for posting on the web. Firing up digiKam revealed an annoyance I didn't notice the first time around, and haven't had to deal with for quite a while.
It shows fuzzy photos.
This is a resize algorithm issue. Both Windows Picture Viewer and Picasa suffer from the same fault, making nice sharp 3000x2000 pictures from my SLR a blurry mess when viewing them full screen. Back in the Rinderpest I replaced them with FastStone image viewer, which is free and excellent and resizes brilliantly for display, but to my dismay they don't make a Linux version. A quick net search didn't pop up any obvious answers, so I went back and stared at digiKam for a while. Eventually I noticed that if you choose to edit a photo, it fires up a different part of the application, one more suited to modifying images. This part of digiKam scales photos most excellently. A quick fiddle with some keyboard shortcuts enabled easy scrolling through a directory of photos, and one-button delete. All I really need. It's a little slow loading and displaying images, but it's perfectly serviceable for now.
Having edited all the photos, I needed to select a bunch of them and whack them onto the intertubewebs for viewing by you shifty lot out there. At first, I just created a separate HTML directory in my document space, and dumped a copy of the album I wanted to select from into it. Then I popped open digiKam, tried to add the new directory as a new album.
Hmm.
A message pops up - “importing photos from new album”. WTF? It sits there and chugs away for about 10 minutes (I told you I took a hell of a lot of photos – we were in the mountains, the mountains, d'ya hear? Scenery was, like, everywhere) and eventually shows a copy of the folder I'd just copied to the HTML directory, now located in the directory where all my photos are stored (and presumably where digiKam defaults to when feeling the need to run and hide from crazy users). Fearing a big ugly redundant cross-referenced hotlinked mess, I just removed the copy and the album, and moved the HTML folder across into my photos directory, which is probably what I should have done in the first place. All was well, and I could commence preparing the album for the web. Deleting photos went fine. Resizing photos went fine (brownie points for digiKam for having a very flexible and capable batch editor).
Rotating sideways photos also went fine. Or so I thought. Upload the web album, pop on to my site, and all looks ok... at first. Then I notice some of the rotated images aren't rotated. Some of them are, but most of them aren't. Scream a bit. Open digiKam again, and there they all are, in their properly rotated glory. Open Konqueror, and, oh dear, half of the bloody things are sideways again. A bit of netting informs me that it seems there are two ways to rotate a jpg photograph these days. One can either actually rotate the image, i.e. get your processor to crunch on the task of swapping all the pixels around, or one can cop out and set an EXIF tag called “orientation”. Software that respects the “orientation” tag will display the image correctly. Software that doesn't (this is basically everything that isn't a photo management or editing application) won't. Gah! Fortunately once I'd figured this out, digiKam has an easy and obvious menu option saying “reset all EXIF orientation tags” which zeros the stupid things and then allows actual, real image rotation. Re-upload the web album, and it's all good.
Getting back to work after a nice holiday is generally unpleasant, and my return to the salt mine was marred by some interesting events on the laptop. First of all, I finally started coding some modelling software I've been bouncing around in my head for a few months on the cluster. I got quite far along with it, and then had to leave work because it was late, cold, dark, and the janitors were starting to look at me in that “don't you have a life?” way they have. No problem, I thought. Pop a copy of the code across onto the laptop, and head for home, heaters, food, and a comfortable chair to sit in. A bit later, I'm bored with TV, so I fire up the laptop and KDevelop, and work on the code a bit more. All ok so far, until I come to compile. “Can't find stdio.h”, and a whole bunch of other errors. Oh, really, huh? Fairly vital component of C there, fella. A quick Googling reveals I need to install the build-essentials package, which apparently gcc installs without, rendering it pretty freaking useless as a compiler for any kind of real program. Anyway. I do so, and compiling works, woohoo. Now this particular code produces output in the form of a series of POV-Ray render files, which are then executed and the resultant images combined together into a video. These bits are done by a separate script we wrote donkey's years ago; it's a nice viz tool for dynamic problems. Running the script shows me my first problem – no POV-Ray, nggh. Very well. Adept finds the package for me in the Ubuntu repositories, so I don't have to resort to binary installs. Run the script again. POV renders happily, and everything seems to go fine. I try to play the mpg file the script is supposed to produce. No mpg file. Nggh again. ppmtompeg, the app we use to convert a series of POV-rendered pics into a movie, is apparently no longer part of the imageMagick package (which I'd carefully installed earlier knowing we'd need it), but now part of the netpbm (!?) package. Sigh. Fine. Install netpbm, and finally everything works. By now I'm tired, and not even interested in watching the mpg, which says a lot if you know me, and know that the model had to run for nearly an hour to produce the three seconds of video it entailed.
Another thing that annoyed me on back-to-work day was that Firefox seems to have become addled again. Opening more than a few tabs at a time slows the machine to a crawl, and bloody-mindedly opening a few more after that kills it pretty much stone dead. A couple hours of fiddling revealed the culprit – NTLMAPS. Well, either NTLMAPS or the Python interpreter it's using, one of the two. Since they're inseparable, I chose to blame NTLMAPS. It's using some stupid amount of CPU horsepower while loading webpages through FF – one tab hits the CPU up for about 50% of its juice, two and it's at 100%, and more than that and the poor machine is just thrashing hopelessly. Poo sticks. Even more unfortunately, FF still has manky issues with using our ISA proxy directly, so for now I'm stuck between a rock and a hard place, and leaving most of my heavy surfing for home.
Finally, in the afternoon I had a free few minutes, so I hauled my machine into the boardroom and hooked it up to our projector for a giggle. The short story here is that Kubuntu is pretty much a dead loss for giving presentations on strange and unfamiliar projectors – don't count on being able to do it. The slightly longer story is that I fiddled for a while with both the ATI control panel (seriously, bleck; it's ten-beers fugly, fix it ATI) and the display manager thingy in the Kubuntu control panel, and neither ever really produced a satisfactory result. The display manager claims to be able to clone display 1 on a nebulously-defined display 2, but it would almost immediately limit me down to 640x480 resolution on both displays whenever I tried it. Painful. Simply leaving everything set as it was after installation and rebooting the machine with the projector connected provided the only moderately reasonable workaround, as the external display would then be woken up (by some PnP action, I suppose) and set to clone the laptop display. Of course, my screen is 1400x1050, and most projectors run at 1024x768, so there was a fair amount of scaling and not-quite-fitting-on-the-screenness going on, but I suppose you could use it for a presentation if you were sensible about leaving reasonable borders at the sides and so on. I need a good fix for this, because a big part of my job is presenting things, but it's not super critical right now. Oh well. Another problem for tomorrow.
A more immediate trouble, and one more to do with a failing of the user rather than the operating system, is that I'm rapidly running out of disk space. My 60GB drive is partitioned 45-15 Windows-Linux, a fact I was abruptly reminded of while trying to plonk some ISOs into my file shares for other people at work. I've got about 2GB of my 15 left, so, well, uh-oh. A couple good photo expeditions, a simulation run or two, and that'll be long gone. I'll probably need to decide sooner rather than later how serious I am about this whole Linux thing, and go with a fresh install plus Kubuntu-friendly partitioning philosophy.
The Kubuntu At Work project is ongoing. After the initial teething troubles were sorted out in the first few days, things have been going fairly smoothly since. There are the odd hiccups, which I'm going to blather about at length, rest assured, but overall, the project is cautiously optimistic to date. Knocking wood. Knocking all the damn wood I can get my fists near.
On getting back from my holiday, I was faced with the first major photo sorting and editing event since switching. I'd managed to pretty much fill my 1GB memory card with pixels, and offloading them onto the laptop (no mean feat – I had to go make coffee while it was chugging away) revealed I'd have my evening's work cut out for me pruning them back, touching up here and there, and selecting a bunch suitable for posting on the web. Firing up digiKam revealed an annoyance I didn't notice the first time around, and haven't had to deal with for quite a while.
It shows fuzzy photos.
This is a resize algorithm issue. Both Windows Picture Viewer and Picasa suffer from the same fault, making nice sharp 3000x2000 pictures from my SLR a blurry mess when viewing them full screen. Back in the Rinderpest I replaced them with FastStone image viewer, which is free and excellent and resizes brilliantly for display, but to my dismay they don't make a Linux version. A quick net search didn't pop up any obvious answers, so I went back and stared at digiKam for a while. Eventually I noticed that if you choose to edit a photo, it fires up a different part of the application, one more suited to modifying images. This part of digiKam scales photos most excellently. A quick fiddle with some keyboard shortcuts enabled easy scrolling through a directory of photos, and one-button delete. All I really need. It's a little slow loading and displaying images, but it's perfectly serviceable for now.
Having edited all the photos, I needed to select a bunch of them and whack them onto the intertubewebs for viewing by you shifty lot out there. At first, I just created a separate HTML directory in my document space, and dumped a copy of the album I wanted to select from into it. Then I popped open digiKam, tried to add the new directory as a new album.
Hmm.
A message pops up - “importing photos from new album”. WTF? It sits there and chugs away for about 10 minutes (I told you I took a hell of a lot of photos – we were in the mountains, the mountains, d'ya hear? Scenery was, like, everywhere) and eventually shows a copy of the folder I'd just copied to the HTML directory, now located in the directory where all my photos are stored (and presumably where digiKam defaults to when feeling the need to run and hide from crazy users). Fearing a big ugly redundant cross-referenced hotlinked mess, I just removed the copy and the album, and moved the HTML folder across into my photos directory, which is probably what I should have done in the first place. All was well, and I could commence preparing the album for the web. Deleting photos went fine. Resizing photos went fine (brownie points for digiKam for having a very flexible and capable batch editor).
Rotating sideways photos also went fine. Or so I thought. Upload the web album, pop on to my site, and all looks ok... at first. Then I notice some of the rotated images aren't rotated. Some of them are, but most of them aren't. Scream a bit. Open digiKam again, and there they all are, in their properly rotated glory. Open Konqueror, and, oh dear, half of the bloody things are sideways again. A bit of netting informs me that it seems there are two ways to rotate a jpg photograph these days. One can either actually rotate the image, i.e. get your processor to crunch on the task of swapping all the pixels around, or one can cop out and set an EXIF tag called “orientation”. Software that respects the “orientation” tag will display the image correctly. Software that doesn't (this is basically everything that isn't a photo management or editing application) won't. Gah! Fortunately once I'd figured this out, digiKam has an easy and obvious menu option saying “reset all EXIF orientation tags” which zeros the stupid things and then allows actual, real image rotation. Re-upload the web album, and it's all good.
Getting back to work after a nice holiday is generally unpleasant, and my return to the salt mine was marred by some interesting events on the laptop. First of all, I finally started coding some modelling software I've been bouncing around in my head for a few months on the cluster. I got quite far along with it, and then had to leave work because it was late, cold, dark, and the janitors were starting to look at me in that “don't you have a life?” way they have. No problem, I thought. Pop a copy of the code across onto the laptop, and head for home, heaters, food, and a comfortable chair to sit in. A bit later, I'm bored with TV, so I fire up the laptop and KDevelop, and work on the code a bit more. All ok so far, until I come to compile. “Can't find stdio.h”, and a whole bunch of other errors. Oh, really, huh? Fairly vital component of C there, fella. A quick Googling reveals I need to install the build-essentials package, which apparently gcc installs without, rendering it pretty freaking useless as a compiler for any kind of real program. Anyway. I do so, and compiling works, woohoo. Now this particular code produces output in the form of a series of POV-Ray render files, which are then executed and the resultant images combined together into a video. These bits are done by a separate script we wrote donkey's years ago; it's a nice viz tool for dynamic problems. Running the script shows me my first problem – no POV-Ray, nggh. Very well. Adept finds the package for me in the Ubuntu repositories, so I don't have to resort to binary installs. Run the script again. POV renders happily, and everything seems to go fine. I try to play the mpg file the script is supposed to produce. No mpg file. Nggh again. ppmtompeg, the app we use to convert a series of POV-rendered pics into a movie, is apparently no longer part of the imageMagick package (which I'd carefully installed earlier knowing we'd need it), but now part of the netpbm (!?) package. Sigh. Fine. Install netpbm, and finally everything works. By now I'm tired, and not even interested in watching the mpg, which says a lot if you know me, and know that the model had to run for nearly an hour to produce the three seconds of video it entailed.
Another thing that annoyed me on back-to-work day was that Firefox seems to have become addled again. Opening more than a few tabs at a time slows the machine to a crawl, and bloody-mindedly opening a few more after that kills it pretty much stone dead. A couple hours of fiddling revealed the culprit – NTLMAPS. Well, either NTLMAPS or the Python interpreter it's using, one of the two. Since they're inseparable, I chose to blame NTLMAPS. It's using some stupid amount of CPU horsepower while loading webpages through FF – one tab hits the CPU up for about 50% of its juice, two and it's at 100%, and more than that and the poor machine is just thrashing hopelessly. Poo sticks. Even more unfortunately, FF still has manky issues with using our ISA proxy directly, so for now I'm stuck between a rock and a hard place, and leaving most of my heavy surfing for home.
Finally, in the afternoon I had a free few minutes, so I hauled my machine into the boardroom and hooked it up to our projector for a giggle. The short story here is that Kubuntu is pretty much a dead loss for giving presentations on strange and unfamiliar projectors – don't count on being able to do it. The slightly longer story is that I fiddled for a while with both the ATI control panel (seriously, bleck; it's ten-beers fugly, fix it ATI) and the display manager thingy in the Kubuntu control panel, and neither ever really produced a satisfactory result. The display manager claims to be able to clone display 1 on a nebulously-defined display 2, but it would almost immediately limit me down to 640x480 resolution on both displays whenever I tried it. Painful. Simply leaving everything set as it was after installation and rebooting the machine with the projector connected provided the only moderately reasonable workaround, as the external display would then be woken up (by some PnP action, I suppose) and set to clone the laptop display. Of course, my screen is 1400x1050, and most projectors run at 1024x768, so there was a fair amount of scaling and not-quite-fitting-on-the-screenness going on, but I suppose you could use it for a presentation if you were sensible about leaving reasonable borders at the sides and so on. I need a good fix for this, because a big part of my job is presenting things, but it's not super critical right now. Oh well. Another problem for tomorrow.
A more immediate trouble, and one more to do with a failing of the user rather than the operating system, is that I'm rapidly running out of disk space. My 60GB drive is partitioned 45-15 Windows-Linux, a fact I was abruptly reminded of while trying to plonk some ISOs into my file shares for other people at work. I've got about 2GB of my 15 left, so, well, uh-oh. A couple good photo expeditions, a simulation run or two, and that'll be long gone. I'll probably need to decide sooner rather than later how serious I am about this whole Linux thing, and go with a fresh install plus Kubuntu-friendly partitioning philosophy.
posted by kittychunk at
2:46 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home