Primitive Computer Vision

I'm working on a project at the moment, which see's me taking screen shots of the system (desktop as a whole) and looking for visual queues on the screen in order to seemingly smartly decided what to do, this is directly on the back of the graphics project I have at work, when something is going wrong, I want to capture the DirectX surface I'm rendering to, save it as a PNG or raw BMP and then process it for "visual queues".

The trouble is, the human eye is a hell of a lot more use than parsing through pixel data, which is pretty much what I'm reduced to at the moment.

I've been looking at implementing a Neural Network to recognise the colours, but Neural Nets have always been a bit of a dark art for me, even though I did two three month courses on AI at uni, Neural Networks only really came up in passing conversation, and then only for the lecturer to try to sell us on the book he'd just written the foreword for - a book I might add which I still have, and which is utterly useless at explaining the concepts at hand... Anyway....

I've also looked at fuzzy logic, and statistical comparison... At the moment I'm happy to stick to plain old comparison, with a tollerance range, so statistics... but I want something smarter to actually see subtler shades later...

That brings me to the other can of worms I've been dealing with, you'll maybe have seen the image processing I'd been doing in C++, I posted some images on this very blog a while back... Well... That was using CImg in Ubuntu, and it worked like a charm, no issues from the off and it just seamlessly worked... Just the way I like things.

Having had that experience I was hoping for just as easy an experience within Windows with CImg... Boy was I disappointed, it just never came together for me, I could not load Jpeg's... Even linking against libjpeg and even libjpeg-turbo didn't work... It was like Visual Studio had an axe to grind, and refused to help.

The awful kluge I've gone for is using the GDI+ Jpeg loader as a Gdiplus::Bitmap*, and then to save the image with the CLSID image/bmp back through Gdiplus::Image::Save.  Utter nightmare, really inefficient, using GDI... gah.. Hate it....

But CImg refused to load the jpeg... No matter what I did... 

As for my two earlier posts about a bug in G++... Well, its not a bug in G++, and its technically not a bug in the GNU STD C++ implementation, rather it seems to be a bug whereby the underlying C API does not meet its own specification.

A chat was very helpful, spent some of this time mailing me back about the problem at hand, but... He was more interested in saying that this was not a bug, but that my code had passed an "out of bounds value"... When I pointed out the C specification for the data type stated that my known value was within bounds, suddenly I stopped getting mails from him :(

The other thing I have done is sign up for Dell's project Sputnik... I'd be very very interested in seeing if they take my application seriously, not least because the XPS series of laptops were high in the running when I was speccing the machine I am writing this very blog post on.  The XPS machines I thought would seamlessly run Ubuntu, and that's the distro DELL have gone with... The reason I didn't get an XPS was because for the specification I'm sat on right now it costed out at over £1100 from them... Whilst I paid only £550 for it, on an off the shelf Intel Chasis... in black, rather than brushed aluminium.

That's not to knock Dell kit, I use Dell kit exclusively at work, have done for about eight years when I forcefully retired my HP desktop and specced a new Desktop Dell, both my home servers are older quad core Dell machines, and my old laptop is a trusty Inspiron 6400... There's a lot of Dell kit around here.

But their support for Ubuntu, even when listed as a Canonical partner was not very forth coming, indeed somewhere I have quotable transcriptions of chats with Dell customer service reps where they speak of not getting any other OS than Windows...

So, Sputnik, come my way, I'll put you through your paces, and rant, rave and be constructive along the way.

(Xel knows he's not going to get jack squat, but hey least I wrong it here).

LIb STD C++ 6 Bug

My post of late last night is actually pointing the finger of blame for that fault at MinGW, my reason for pointing my beady little finger in that direction is that the DLL given, causing the crash came from their repository.

 

But, in true computing style they don't handle bugs in that code, it is actually a third party product from GNU, libstdc++.

Taking a look at that site and I can't for the life of me see where to report this problem, as I point out on the bug I've posted on the MinGW tracker it might be an OS API bug, or it maybe something in MinGW, or even just something in this library... But I can't be sure, without that is, delving into the GNU code - not something I'd relish

Anyway, right now I'm looking for some bug list, mailing list, or tracker for the GNU libstdc++, before I go and start to pull my hair out.

---

The worst thing about this is that GNU is an open source project, it produces some great work, but unless you can work through the pages of dross which surround it, the cloud of obfuscating crap that, in my opinion, follows most all open source projects, without crawling past all that crap you can't easily contribute feedback like this bug.

I'm no rookie programmer, so it would be lovely to go look at this bug for them, but I can't easily do that.

---

Update

I've gotten the e-mail address of the maintainer for the "Active Issues" list regarding the library over at GNU, I got this from the top of their documentation about the library.

But once again, I can't be sure this poor person wants to know this trivial snippet of information, they'd certainly go mental getting dozens of mails a day from such a source of none-sense... But, I'm still unable to decipher where to send bug reports for the library :(

MinGW C++11 Chrono Library Bug

I've had a rollercoaster of a day, I was awake most of the night in agony, left off work (after calling the boss - or rather the wife did) and I went to see my GP, who put me on some really strong drugs to calm my bones, seems my heel bones are really not getting on with the rest of my body... Wierd...

Anyway, when we got back from this GP visit, I sat down to expand my mind a little in the direction of C++, I was specifically going down a check list of some work items I needed to optimise, and one of the things I was looking at was timing in the systems... I wanted to build on the very fast file system library I've written in C++ for use in C# with a library to very quickly handle times.  Not that the C# support for times is not good, but its not very useful for some of the more precise measurements I wanted to take.

So, after a bit of reading about POSIX time, and Windows API time, not to mention looking at Boost::chrono I started to check out if there were any additions to time handling in C++11, an obvious place to look, but strangely the last I went to.  Anyway, seems much of the boost::chrono library has been accepted as standard in C++ STL, and I quickly set about reading what I wanted...

My next problem was getting this all to work in some compiler, I tried out a bunch of things in g++ on the laptop and was happy enough under Ubuntu.  But I need this for work, that means Windows...

Introducing MinGW... I grabbed the latest get-install executable and set about installing it, then started to throw together some code, my first test program was to simply output the epoch, now, min and max time_points for the system clock, this is a standard bit of demo code, and I lift it straight from:

Click me to visit Amazon and buy this fab book.

Page 152 if you're interested... Anyway, I typed the code in and here is how it looks:

#include <string>

#include <iostream>

#include <chrono>

#include <ctime>

using namespace std;

using namespace std::chrono;

const string asString (const system_clock::time_point& p_TimePoint)

{

string l_timeString ("");

try

{

time_t l_time = system_clock::to_time_t(p_TimePoint);

l_timeString = ctime(&l_time);

if ( l_timeString.size() > 0 )

{

l_timeString.resize(l_timeString.size()-1);

}

}

catch (exception& l_ex)

{

cout << "Ex: " << l_ex.what() << endl;

}

return l_timeString;

}

void shoo ()

{

try

{

system_clock::time_point l_tp;

cout << "Epoch: " << asString(l_tp) << endl;

l_tp = system_clock::now();

cout << "Now: " << asString(l_tp) << endl;

l_tp = system_clock::time_point::min();

cout << "Min: " << asString(l_tp) << endl;

l_tp = system_clock::time_point::max();

cout << "Max: " << asString(l_tp) << endl;

}

catch (exception& l_ex)

{

cout << "Ex: " << l_ex.what() << endl;

}

}

int main ()

{

shoo();

cout << "Done, press ENTER" << endl;

cin.get();

return 0;

}

Next I set about compiling under windows...so with the code above saved as "C:\Code\Test.cpp" I get a command prompt and did this:

path=%path%;c:\MinGW\bin

cd \Code

g++ -x c++ -Wall -std=c++11 Test.cpp -o Test.exe

I know I need to copy a couple of dll's from the MinGW bin folder (libgcc_s_dw2-1.dll & libstdc++-6.dll) before I can run the application.  With them copied over I run the app... And... I get a crash...

I'm not using a debugger at the mo, just trying out this little bit of example code, so I'm unable to delve too deeply into what's going on... However, after a little trial and error from the four system clock calls I know its got to be one of them, and just narrowing it down I find out that using the generated "system_clock::time_point::min();" is throwing the spanner in the works.

The other calls all work when being passed through my code, just the minimum time_point does not?!?!?!

Checking around the internet, I find no-one else mentioning this, I see the use of the minimum time point a lot, and I see it in a lot of examples... But this crashes...

//l_tp = system_clock::time_point::min();

//cout << "Min: " << asString(l_tp) << endl;

Rem these two lines out, and rebuild... All works fine!

So, am I able to generate a min time point?...

auto l_tp = system_clock::time_point::min();

Yep, this works... so, this leaves my passing it to asString...

The only real call of any logical significance in there is "system_clock_to_time_t"... voila, that's the problem, passing the time_point min to that function results in a logic error exception... but why?... That value should be output easily enough, and represented as a time_t... all the references I have say it is so...

So guys and gals, passing your time_point::min to system_clock::to_time_t will crash on MinGW output applications running their current, as of the time of writing, C++11 libraries... :(

STL Iterator versus Auto (C++)

I've had an interesting time with a piece of C++ overnight, I've been using the std vector class to hold a set of values, let say integers, and I've been interating through the contents of the vector to give me the list when I need to go through it.. I've had no issues with this, here's my code:

#include <vector>

#include <iostream>

using namespace std;

void foo ()

{

vector<int> nums;

nums.push_back(1);

nums.push_back(2);

nums.push_back(3);

for (vector<int>::const_iterator itr = nums.begin(); 

itr != nums.end(); 

++itr)

{

cout << (*itr) << endl;

}

}

This has worked fine, been fast, and easy to comprehend... But I let someone else review my code, just a snippet, and they came up with this rather bolshy "you must use an auto" comment and changed the code, thus:

for (auto pos = nums.begin(), end = nums.end();

pos != end; 

++pos)

{

cout << (*pos) << endl;

}

I took this on the chin, never complained, and had a look at it, the code certainly worked, just as it always had... So I immediately thought, is this another case of change for changes sake... something which has been rearing its ugly head in my direction time and again for weeks; months in places...

I started to do some timings, here's the complete timing code:

void autoUseFoo()

{

    vector<int> l_vector = DefaultVector();

    int l_timeA, l_timeB;

    timespec l_StartTime, l_EndTime;

    int i = 0;

    while ( i < 100 )

    {

        l_timeA = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &l_StartTime);

        for (auto pos = l_vector.begin(), end = l_vector.end();

                  pos != end; 

                  ++pos)

        {

            cout << (*pos) << endl;

        }

        l_timeB = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &l_EndTime);

        OutputTime (c_Auto, l_StartTime, l_EndTime);

        i++;

    }

}

void autoIteratorFoo()

{

    vector<int> l_vector = DefaultVector();

    int l_timeA, l_timeB;

    timespec l_StartTime, l_EndTime;

    int i = 0;

    while ( i < 100 )

    {

        l_timeA = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &l_StartTime);

        for (vector<int>::const_iterator pos = l_vector.begin();

                  pos != l_vector.end(); 

                  ++pos)

        {

            cout << (*pos) << endl;

        }

        l_timeB = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &l_EndTime);

        OutputTime (c_Itr, l_StartTime, l_EndTime);

        i++;

    }

}

As you can see, I clock the time before and the time after the loop, one using a const_iterator, the other using an auto-range... My argument being that because in this isntance I don't need to change the items being output, to use the auto results in needing to go through a construction (of the auto object) unneccesarily, slowing my code.

I produced this code, and I came up with exactly what I expected, auto results show a large spike of over 12000ns to set up, and then approximately 4300ns to go through the vector... Whilst the const iterator shows no spike and performs the loop through in an approximate average of 4200ns... That, to me, tells me my code is faster, its also in my opinion easier to read, and more easily changed to support better casting when we use complex objects, say to call functions... Especially is one typedefs the ugly "vector<int>::const_iterator" type to somethig more legible.

I showed my retort, I infact have written this up in my project notes, and given reasoning and code examples as well as timings taken over 10, 100 and 100,000 iterations of the while loops shown above, each and everytime the iterator is faster than the auto... Yet this person refused to listen, refused to even look at my reply... Their input "auto is right"...

This is code, there is no right or wrong, they are just different ways to get to the same conclusion, just that my solution results in quicker code and hence a slightly better user experience... and I accept that its only 100 nanoseconds on my timings, plus the spike, but if I were willing to accept that today, what would I accept tomorrow?... How much worse could the user experience be?

Burning up, or shutting down, the Mini-Computer

I've decided today to tell a story, its a true story, and it bares some interesting information and history.  You see, I used to work for a company called "Claremont Garments", at the factory in Selton, and I worked in an IT support Role... I took over the role from a guy called Jim... The last time I saw Jim he fell out of a doorway near drunk when I picked him up for the annual departmental curry... But anyway, I was a student at the time... Studying Software Engineering.

The company ran an NCR brand mini-computer, running serial lines through multiplexors out to the distant sites, using dedicated comms lines.  Meaning in the far off factories there were green screen terminals showing the computer screen.

At the time it was the sunset of the mini-computer era, I don't think very many companies still run in that fashion, though some, like the one I work for now, do still have powerful servers running systems which are really just old software which should have a terminal, but which have been given a GUI.

But at the time, I was introduced to this NCR, and its AST backup, machine I was told it had to have an ALWAYS UP rule, I was shown how to make a call on the very expensive support contract, then told the push button code for the door, and shown inside the cave of technological delights.

It was all pretty old stuff, a wire wrack, with monitors, keyboards, UPS's and other stuff, there was networking switches running down the right of the room, and computers down the left.

But as I'm being shown what each computer does, I notice that in the stream of air from the air conditioner there's black flecks... Soot... I look at the unit, its a nice newish clean looking thing... Where's this black coming from... I glance down, nothing, glance up... There are three monitors on the top of this wrack of machines, the right hand one is on, but looks fuzzy, and the black particles are floating out of it... The ceiling tile is slightly discoloured with heat... That bastard thing is on FIRE!

Well, I shift back, and point it out, Jim to his credit dives in to his elbows and grabs this thing down... As I reach around his arms and unplug it... But now, he's holding a burning monitor over his head, and is stood in the server room... There are two doors to this room, I sling the one to the right open and Jim hurls this monitor over hand into the corridor, where it just sits black specks floating and all...

However, turning back around the chat hired to write code for the mini-computer, Don, is skidding into the other doorway and lands on the floor full length staring at the NCR... "What have you done?"  he cries "It's gone off"...

I look as puzzled as Jim, who retraces his steps... Whilst valiantly saving the server room from fire, he'd stood on a pile of wires, one of them was a coil of power lead, it was the lead from the UPS to the NCR... The NCR had lost power, instantly...

OH SHIT... Don and Jim reboot the machine, something I take care to learn about, but ironically in my whole time there, never had to do.

But then I take a look at the wire Jim "Pulled" out... it has screw fixings, it should have been screwed into the UPS and the NCR, but it wasn't... The person responsible for it not being screwed in, forever after, ridiculed Jim for unplugging the machine... But Jim had stood a good 4 feet to the side of the NCR itself... this chain of catastrophe should never had happened.

However, it did, and instead of Jim being remembered for his efforts to save the place burning up, he was always jibed and remembered for unplugging the NCR.

ARGH Using Break before Case in Switch Statements

I have a new Number 1 for my “Most Annoying pieces of Syntax use” list… A new annoying item on my personal top ten of code peeves, jumping to the number one position is this:

enum cElements {  One, Two, Three };

eElements element = <something>;

switch (element) {

      default:              throw “unknown element type”;

      break;case One:       HandleOne();

      break;case Two:       HandleTwo();

      break;case Three:     HandleThree();      break;

}

The most annoying thing about this is that it’s a rather intelligent attempt to solve the “default” being forgotten problem, to enforce the default as the first item in the code is pretty neat, but it appears the only reason for their doing this is so that they then use the default stanza’s “break” as the first command before the first case to preserve their bizarre formatting of the end of the last stanza (break) with the selective part of each following stanza (case)… And then they stick a finalizing break after the last case.

The lack of spacing makes the code hard to follow, indeed the use of the breaks in this way make the control flow hard to follow.

And if you don't know how this could be better structured, then please, please go learn, go find out... Scott Meyers has damn good books on C++ and they contain nice style tips!


----- 


Update - I don't know why this text has strange background colours, and the blog interface won't let me see the post in a WYSIWYG mode... grrrr.... Gief me the old interface back.

Prometheous Promise Pants

I'm going to sound a little daft here, but I went to see Prometheous yesterday, and I came out feeling... really really angry about it... I had this idea in my head of it explaining a few things with the Alien franchise, with some proper "Oh my god we can't escape this thing, oh my god no matter how careful we are, oh my god its loose" style terror... Instead I sat there, and was treated to an impressive visual display, but no real meat on the bones of the story.

The eligmatic looking "Engineers" the star jockey of Alien fame... Turns to be a really rather confused, unexplained, unfocussed character... There's no real explanation for them, no explanation for anything... Its a film without a story except to cause a follow up film, which it will...

And I sat there thinking... This is Ridley Scott... This is... This is shite.

It annoyed me on so many levels, firstly... Scientific method... There's an alien world, a archeological site, they know nothing about... "Yeah take your helmet off man"... good idea... NOT.... There's these things they change with activity... open the chamber fuck it up.... I mean Howard Carter understood the problems of opening tombs why in 2093 don't we...

Then the date... 2093.... I know Ridley Scott will be dead by then, but I don't plan to be... I'll sit there and think... "Oh yeah another spaceship film full of shit".... and that's what I think about it now.

The unexplained attack with the DNA stuff by the robot on the scientist... There was no point in that... I mean... He ends up getting fried... so why bother?... The alien in her womb... pointless... The Star jockey chasing her down... Pointless... The head of David... "I know we've had our differences"... yeah... erm... WHEN?... Did I miss part of the plot here, was the Differences CUT from the film?... Because... really... there were no differences... there were no crossed words... Save for him taking her cross off her, which he did do for a reason and nicely.

I mean... It was all hung together so precariously...

Charlize Theron's character... she didn't need to be there at all...

Guy Pearce... Playing an old man, decent make up... they made a good effort... his feet were old... But did anyone notice, as the scene flicks to the mid-distance and the Robot is handing his slippers, the feet Guy slips into the slippers were young?... It broke the illusion....

It has, for me, ruined the imagary of the Star Jockey... For that first ship was crashed on some distant, very deep space moon, and was hundreds of years forward of this shit film... This shit film was two years of intersteller travel out... two years.

You know what... I can't slate it enough... It was bad, poorly put together, poorly scripted... not terribly well cast... and ruins the work that's gone before... They'venot done a George Lucas style reworking... but they've reworked something that didn't need reworking.