Thursday, February 19, 2009

To Flip or not to Flip, Image Orientation in Directshow

Here's a good insights regarding the cases where you need image flipping when coding filter in Directshow. There's quite lengthy narration on the history and the details on the article, but here's some important point :

  • Some Color Format use top-down orientation (the start of the image is on upper-left corner, e.g: RGB) other use bottom-up (start from lower-right corner, e.g: YUV)
  • The given height value show whether the image follow the orientation. Positive means the data follow the orientation, negative means it is inverted
With that two point in mind you could decide when to flip it or not. For example, if you need image with top-down orientation and got RGB with positive height value (means it's bottom-up oriented) you need to do the flipping while if the height value is negative (RGB but with top-down orientation) you don't need to.

Thursday, February 12, 2009

Using Workrave

I am a user of a Workrave for sometime now. I was once having a quite disturbing eye-strain that made me need to rest from computer activity several days. I decided to avoid to have to gone through it again and it was the time workrave starting to be on my desktop (with RSIBreak as it's counterpart in KDE one).

Workrave is the kind of the application that you need to tweak a lot to be really effective. It tends to break my flow in my early use. I am quite used to it now and the break has become more natural and less distracting. Here's the current setup and convention that I use currently (note : I do mainly programming/software/research work) :

  • per 15 minutes microbreak. This correlate nicely to one simple microtask, so when it hit it usually near the end of the task or start of the new one. This way, the break can also be used for retrospecting on what currently being done or the next thing to do. The trick with microbreak is not to treat it as a break where you put everything down, but as a short pause where you still hold your current memory on your mind but let your eyes, breathing, brain and muscle rest and stretch
  • per 1 hour reast break. One small task is usually within 1-hour boundary and even for 2 hour or more task, 1 hour break and evaluation is a good way to keep it focused. For this kind of break, I walk around, do some stretching or just get outside
  • no daily limit set :)
  • skip break button is active but not to be pressed. I was once doing skipping a lot that it become a habit. This kind of usage is really missing the point of using it at all, so I deactivated skip button after it. However, after sometime, think it's better to have it available for emergencies. I activated it again but with a stricter use this time
  • postpone button is active, set to three-strike rule. I don't think postponing break should be disable if you want to have minimum distraction to your working flow. I rarely postpone on microbreak alarm but quite often on rest-break. The reason is that you need to align task completion and/or setup necessary context-switching to be able to have effective long break which is quite useless if your mind is not cleared yet
  • idle-detection is on. I find that if idle-detection is off the break is really distracting and could hurt productivity and flow. The reminder would popup while I am thinking and doing nothing on screen.
Using break-reminder application is not as simple as I first think but it's quite worth it. The above list has been stable for quite some time now. I find it quite suitable for my work-style and I haven't had eye-strain incidents lately so I guess it's on the right area of balance. You might find it suitable with yours or you might not, but the bottom line is to search the one really suitable for yourself.

Tuesday, February 10, 2009

Use Personal/Manual Clipboard while Coding

Coding involve lots of copy/cut and pasting and many of those are hard or confusing to do if you are relying only on unseen standard clipboard buffer. You need more powerful clipboard function that only full text editor can provide.

I find it helpful to use text editor as "manual" clipboard when coding and only relying on standard clipboard for only the tiniest need. I personally use JEdit for that, as it is also my all-purpose text-editor, but any text-editor will do. I use it liberally to put everything that has transient existence there. Here's some example when it can helo:

  • changing system's environment variable like PATH. I copy paste the current one to JEdit twice and edit and paste back the second one (much easier than to have to edit it on the dialog box like on Windows), the first one is for backup when something goes wrong
  • edit critical code. I copy paste the existing one to JEdit before editing the one on the IDE. I do this for relatively long code piece while for short ones, I do my safe-coding on it.
  • store frequently-referenced code. There are part of code that you frequently need to refer to while you code on several places e.g: important struct that being passed around everywhere. I copy it to JEdit for convinient referring. You will need to have dual-monitor setup to have this felt really useful although switching between JEdit and IDE still a bit faster then switching back and forth within one IDE
  • copying several piece of code on several places and not exactly the same everytime. I wouldn't want to do it without having text editor to buffer code pieces for this. This kind of coding task is probably the fastest way to confuse your mind and ruin your day :), you need strategy and buffers to do it safely and, hopefully, fun
  • editing build config. Build config usually needs a lot of copy and paste and although you could do it using system's clipboard you will find that editing and storing related part on the text editor first will ease the task a lot. It will minimize jumping and recopying that will almost certainly happen often
  • cutting code that you are not really sure you want to see that part you cut is gone forever (beyond the recovery-limit of undo)
That's just some of what I can think of right now, there will be lots of other cases you will find much easier to do if you remember you can always buffer it to text editor first.

The more powerful text editor will help you even more relative to less powerful one, you will have all the leverage that the text editor have as the leverage of your "manual" clipboard too like syntax-coloring, structure parsing e.g: SideKick in JEdit, autosave.

You could think your text editor as a side kick of your IDE, it shares the burden and make coding less burdensome.

Friday, February 06, 2009

Boost's program_options versus TCLAP

I have upgraded Boost to 1.37 and I feel like trying the program_options (po) part. I wrote about TCLAP sometime ago and pretty happy with it so far, so I would like to see how this boost's one compare with it. If it works well, I will consider replacing tclap with it and have less scattered dependencies since it is part of boost.

However, after the first compile, I don't feel like it's going to replace tclap for me, at least not for simple-to-middle argument parsing needs. Here's the comparison.

Adding Arguments

Here's in boost's :

po::options_description desc("Allowed options");
("help", "produce help message")
("compression", po::value<int>(), "set compression level")

and here's adding option in tclap :

CmdLine cmd("myProgram", ' ', VERSION);
ValueArg<int> arg0("","arg0","Description",true, 0, "Type Description");
cmd.add( arg0 );

which is more comfortable to me. The boost's one look a little counter-intuitive (in standard C++/OOP way). Here's from the documentation on why it has the form like that :

The add_options method of that class returns a special proxy object that defines operator(). Calls to that operator actually declare options.

I could live with a little hackery and magically-looking code, in fact sometime I like this kind of thing, so I could tolerate it a bit, but the next difference put me off.

Parsing and Accessing Arguments

Here's how you parse and use the arguments in boost's :
po::variables_map vm;
po::store(po::parse_command_line(ac, av, desc), vm);

cout << vm["compression"].as<int>();
and in tclap :

cmd.parse( argc, argv );
cout << arg.getValue();

I doubt that I need to explain why the second one looks better, but here it goes anyway:
  • the type info is no longer needed to be typed since it is aumatically resolved
  • I have direct access to the arguments instead of having to access it through argument map data structure
  • overall easier syntax
Of course, if you look into it more thoroughly, boost's po is a much more robust and powerful argument parser. If you make something like compiler or a program with tons of tweakable configurations, it will be a very handy tool in your hand while tclap might probably push you to make workarounds and compromises. Still, in general case, I would use tclap by default unless there's a hint that I need to use boost's po instead.

Some note on code snippet :
  • I don't use exact one-to-one variable naming, just conviniently and lazily copy-paste them, but the general idea is more or less the same
  • no error/exception handling shown, but both use quite similar try-catch scheme

Thursday, February 05, 2009

Multipanel in AllinOne Sidebar Extension in Firefox

I find Multipanel when I installed Firefox's All-in-One Sidebar extension. It opens up the page what you currently viewing right now on the sidebar in single column view by default. It is very useful when you want to have certain page to be sticky like when the page is in a referential nature.

However, the very good thing about it is that it opens up any link that you click on that sidebar on your current main tab instead on itself. One really major use that I find for it is when opening a page with some kind of table of content on top that has links to anchors within the same page or links to other page. Without it, I have to switch back and forth within the same page or switching between tabs which is distracting and break the focus. With Multipanel, I just load the page on the side and click the links from there, very handy.

Wednesday, February 04, 2009

What does Visual Means in Visual C++

Visual in Visual C++ does not neccessarily means because you can do your programming by manipulating graphical symbol ala Model-Driven stuff or design GUI using designer (although now you could much more conviniently than on the age of Visual C++ 6.0). It seems to me it means more that :

You can not do development with it (at least not conviniently) without mouse.

I do my early work using gcc and vi, console/xterm (it's kterm in KDE). With that as a background I don't question much the "visuality" of Visual C++. To me, it basically means visual in the way that it is a graphical IDE as oppose to a console/terminal-based one. I think that will put our expectation in a more apropriate place.

The confusion probably comes from the fact that it is bundled within Visual Studio where you have Visual Basic/C#/J# in it that have more "visual" feel to it i.e: start new windows forms project, add buton, double click the button, add code within event handling skeleton, add more widgets, add more event handlings and so on.

Monday, February 02, 2009

To Use or Not to Use Libraries

My work lately reminds me of a comment on Slashdot long ago about the use of library. I did not keep the link of it but it goes something like this :

  1. When you make a code that will be (re)used by other developers e.g: libraries, components, avoid using third party library/framework whenever possible
  2. When you make an application that will be used by the end-user, do use libraries freely as you needed as long as you bundle them in your installer/package
I think it's a good guideline.

The first item make the second one possible. If library developers use third party libraries liberally, the application developer would have to bring all those burden along with him including potential conflict with other included libraries, and it's dependencies, and it's dependencies of dependencies. Well, you get the idea.

Sunday, February 01, 2009

Setting up Environment for Directshow Development

We were upgrading our Directshow SDK since it is felt a little outdated now. We were still using the one from the age where it is still under DirectX SDK. There's currenlty nothing felt wrong or there were errors, we just would like to have it not too far from the latest release available to avoid the code stuck too long in the past.

The needs :

  • Multimedia Application Development : need standard Directshow library
  • Filter Development : Directshow Baseclasses would need to compile

To fulfill those, The current state of available SDKs from Microsoft require me to install two separate (and large) package, that is :
  • Microsoft Windows SDK : to access what is considered to be standard feature available in Windows. Apparently, now Directshow is considered standard so it is included in this base SDK while it used to be under Directx SDK.
  • DirectX SDK : you could only do straightforward Directshow development like file playing using Windows SDK, you need another package (below) if you want to access the complete API in Directshow since some headers from DirectX is still needed when accessing more complex part of the Directshow API. You'll see why it is needed below.
My existing setup is Visual Studio (VS) 2005 Professional SP1 on Vista. I have also Visual C++ 2008 Express installed.

A good page for all things Windows SDK can be seen here. It contains a list of existing downloads, the latest available together with the previous ones, and there's also links to supportive materials i.e: forums, related SDKs and downloads.

I started with installing Windows SDK 7 since it's on the top of the download list (It is cutely-named "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: BETA"). The download took a while, and you better have something else to do rather than waiting for it. The installation went long also but finish well. I checked the VS and it seems it's not registered yet despite the release notes say that if you install the SDK after you have the VS installed it should register itself. Simple enough, there's Visual Studio registration tool on the Program Menu to do it semi-manually.

It does not work, however, at least not with VS 2005. When I try to build a simple player, it complained about Strmiids.lib debugging information corrupt. Testing with Visual C++ 2008 Express prooved succesful. After googling around, it seems the error usually come when the SDK no longer support certain compiler. So, I get the next SDK on the list (6.1, a.k.a "Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5") and do some more waiting...

Long story short, it fixed the problem, I could build the simple Directshow application with it. But to make something more complex you'll get into trouble with dxtrans.h not found. So, according to this, I need to download and install DirectX-SDK-August-2007. So, time to download and wait some more...

After the install (it automatically register itself to VS), It directly fixes the problem and unlike being said on the webpage linked above, no manual copying of files needed.

Now the development environment ready for some "fun" time with Directshow. Hopefully, no more waiting for SDK downloads needed.