Harshdeep 2.0

January 12, 2009

Latest in Music

Filed under: Latest in Music, Music — harshdeep @ 6:18 am

This time when I came to visit Delhi, I realized that I’m completely out of touch with Bollywood music. When I stayed here, it was literally impossible to not know the latest chart busters by heart. You listen to them on FM in car (the distances and traffic of Delhi means you spend quite a lot of time in the car) and on TV at home – even news channels play Bollywood music sometimes. They are inescapable.

It’s a totally different story in the US. Sure there are ‘top 10’ websites where you can look up the names of the popular songs. To listen to them, I would generally search for individual songs on Youtube. Very inconvenient.

Latest in Music

All I want to do is stay in touch with the latest in music. So I wrote a script to scan those song listings on the web, search for the songs on Youtube and show all the videos at one place – www.latestinmusic.com. The script also generates an RSS feed so that the videos of new songs appear in my aggregator (I use and highly recommend Google Reader) automatically. All those songs are also assembled in a playlist using Youtube API so I can hear them one after the other without having to manually switch between them.

The song listings are scrapped from Dishaant, Planet Bollywood and Raaga. Once I was done with this, it was not too hard to do the same thing for English songs as well, scrapping the song listing from iTunes’ US and UK top lists here.

Youtube search with a song title (along with the movie name for Bollywood songs and artist for English ones) is definitely not guaranteed to return the actual song as the first result but it’s uncanny how often it works right. Check it out for yourself and let me know if you have any comments or suggestions.


May 19, 2008

Indian Superheroes

Filed under: Cartoons, Comics — harshdeep @ 3:37 am

The other day I was waiting for a friend for a movie at the theater in a nearby mall. To while away some time, I entered a comic store.

I was surprised to see an entire shelf full of Indian titles – Devi, Sadhu, Snakewoman, even Ramayana 3392AD which – the name says it – is a futuristic adaption of the epic story. The artwork is astounding and the story settings don’t look bad. The company behind the titles is Virgin Comics which has people like Richard Branson and Shekhar Kapur as founders. One of the founders, interestingly, is named Gotham Chopra.

I did not see Pavitr Prabhakar on the shelves. He is the Indian Spiderman with really bad sense of dress. Apart from what seems like a upper-half-skin-tight-lower-half-free-flowing kurta, desification is complete in characters’ names as well – he fights Nalin Oberoi, not Norman Osborne and Mary Jane becomes Meera Jain. The storyline remains almost the same though.

The new brigade is fine. But remember the old home-grown favorites – Nagraj, Super Commando Dhruv and the rest of the Raj Comics gang? Some quick googling revealed that they are still alive and very much kicking. The latest Super Commando Dhruv offering is called World Wide Web. Obviously it’s about giant spiders. Ahhh… the nostalgia

March 14, 2008

Targeted Advertising…

Filed under: Uncategorized — harshdeep @ 8:04 pm

…is obviously in. Look at ABC.com – it shows ads of Jimmy Kimmel show while I’m watching Jimmy Kimmel show. Bull’s-eye 🙂

January 19, 2008

Poisson Image Editing

Filed under: Graphics, Imaging — harshdeep @ 8:42 pm

After spending a totally laidback month in Delhi, I’m now back in Austin for the second semester. I did a couple of interesting projects towards the end of the first semester.

The first one was for Computer Graphics course with Dr. Bill Mark. I implemented an influential SIGGRAPH 2003 paper by Perez et al, Poisson Image Editing (PDF). The technical details are there in the paper. In this post, I’ll just show some interesting results.

The paper provides general machinery for handling several important image processing tasks – seamlessly cloning one part of an image to another, for example. Say we start with the images of Mona Lisa and an angry woman.



Now, say you want to see how Mona Lisa would have looked if she was really angry at Leonardo. You select a part of the angry woman’s face and paste it on top of Mona Lisa’s in, say, Photoshop. Now, you don’t want to spend too much time with the Lasso tool, or something like that, carefully selecting parts of the source image and adjusting its color, contrast etc so that it doesn’t look out of place when you place it over the source image. You have just enough time (or inclination) to make a rough selection like this.

Mask (The selected region is NOT darkened)

When you simply paste the selected region over Mona Lisa’s face, this is what you get.

It looks much better with Poisson Image Editing.


The basic idea is to modify the copied pixels under two constraints

  1. The pixels at the boundary should remain the same as the target image
  2. The pixel gradient in the copied region should be the same as the gradient of the source image

Other effects can be generated by modifying either of these constraints. Let’s say we want to seamlessly clone objects that have transparencies too. For example, say we want to paste an airplane complete with smoke trails over a bunch of clouds. With the original method, this is what we get. Notice the blurring of clouds around the smoke trail.

Essentially we want to preserve important structures in both the source (smoke trail) and the target (clouds). We can do this by modifying the constraint 2 above. The pixel gradient in the copied region should be the same as the stronger of the source and target gradients at each pixel. The paper calls this method mixing gradients. This is what we get now. Notice the clouds showing up between the two smoke trails.

Now, say we have a small image that we want to use as a texture. Such an image is expected to tile seamlessly (so that it doesn’t produce artifacts when wrapped on a 3D surface). But when the original image is tiled, it shows considerably distinct seams between the tiles.

Original Texture

Tiles with distinct seams

This intuitively looks like a problem that Poisson equations can help us with. All we need to do is to treat the entire image as the area to be copied, and modify the first constraint such that the pixels up north are the same as pixels down south and similar with east and west sides. The resulting texture image does not look very different from the original, but we no longer see any seams on tiling it.

Processed Texture

Seamless Tiling

The method generally works well, but it makes some assumptions. One of the strong assumptions is that the neighborhood where we are going to insert an object is similar to its neighborhood in the source image. If this is true, we don’t have to change the pixel values of the object too much to satisfy the boundary condition above (constraint 1). To understand this, let’s try to put the lion’s face in a pool full of people.



And bang, this is what we get. Interesting effect, but not exactly what we wanted. Colors in lion’s face had to be changed too much to satisfy constraint 1 above.


We get a better result when we try to clone the floating boy in the next image. This is because he is already in a bluish background. Smaller modifications are required to be made in the color of his hair and body to satisfy the constraints.



In general, Poisson image editing can be used to selectively operate on a particular object in an image. Maybe you want to adjust the intensity of one object and not the rest of the image. Or maybe you want to make the entire image black and white, but leave one object in full color. You don’t have to tenuously select the object – a rough selection is all that’s needed.

As I mentioned in the beginning, this is a widely cited paper. Here are two follow-up papers, both from Microsoft Research, that are very useful.

  1. Drag-and-Drop Pasting, Jia et al, SIGGRAPH 2006
  2. Poisson Matting, Sun et al, SIGGRAPH 2004

I did another project last semester that I want to write about, but I’ll save that for another post.

November 20, 2007

Narayana Murthy

Filed under: Uncategorized — harshdeep @ 4:57 am

On Thursday, I attended a talk by none other than Narayana Murthy, the legendary co-founder of Infosys. It was hard to believe that the short humble person on the stage calmly explaining the benefits of a flat world (read outsourcing) is the creator of one of the biggest Indian IT companies and an incredible money churning enterprise.

He was here in UT to deliver the first in the Dell Distinguished Lecture series. The title of the talk was “Do we need a Flat World?” He put forward some interesting and well researched ideas, but it’s such a widely debated topic that it’s hard to find something truly novel to talk about.

Thanks to Vijo, I also got a picture taken with the big man himself.

October 16, 2007

My Ray Tracer Artifact

Filed under: Graphics — harshdeep @ 7:50 am

I just completed an artifact for the Ray Tracer that I worked on as part of an assignment for the Computer Graphics course that I’m taking this semester.

One of the coolest things about Computer Graphics is that you can immediately see the results of your labor. Here is the artifact that I’m going to submit.

There is nothing path-breaking about this example. It just shows off the minimal set of features that every ray tracer has.

The spheres are placed according to a simple recursive algorithm, and the planes are meant to make the 3D placement of spheres more evident. The material of each object is both reflective and refractive. The central sphere is mapped with a texture and the diffuse color of the rest of the spheres gets darker with the depth of recursion (smaller ones are darker than the bigger ones). There are four point light sources in the scene. Each ray can bounce (reflect or refract) up to 4 times.

This is how the image looks if there is no reflection and refraction.

October 5, 2007

What is in a name?

Filed under: Uncategorized — harshdeep @ 12:49 pm

For quite some time, Gmail has been repeatedly showing me Vicks ads irrespective of the content of the messages I read. Reason – their tagline is “Harsh weather”. And Harsh, being part of my first name, appears in most of the mails in my mailbox. So even though the weather is pretty pleasant here in Austin, I keep getting this ad. So much for targeted advertising.

During the first few weeks in the US, I tried to emphasize that my name has nothing to do with the English words ‘harsh’ and ‘deep’ by telling them that they should pronounce ‘Harsh’ as in ‘Hersheys’. But I gave up when all they could remember a few days later was ‘that chocolate guy’.

September 10, 2007

Back To School

Filed under: Uncategorized — harshdeep @ 3:13 am

This time I’m writing from Austin, Texas. And this is where I will be writing from for most part of the next 2 years as I complete my Master’s in Computer Science from University of Texas at Austin. Hopefully, I’ll do some research too.

At this point I could go into any of the following trajectories:

  1. Adapting to the academic environment after spending 3 years in the industry
  2. Cultural shock in the US – no amount of Hollywood diet prepares you for the 6th street
  3. Home sickness
  4. 7 wonders of Austin

But any of them will make it an unbearably long post. I must mention my new roomie, Sudipta as he has written extensively about such stuff. He is a second year MS student and a father figure to many first year students.

Here is a video I shot at the Flugtag. AFAIK, it was a calculated stunt and the pilot is still alive.

Hook’em Horns!

June 21, 2007

Reusing High Level Modules – Dependency Inversion Principle

Filed under: Design Patterns, Dev, Geek, Programming — harshdeep @ 8:14 am

It is easier to make a low-level module reusable, than a high level module. Firstly, a low-level module generally has clearer goals (do one thing and do it right), and wider usability (number of people who need a generic stack is much more than those who need a document indexer). Secondly, a low-level module has less dependencies on other modules. When one moves a module from one application to another, one also needs to move all the modules that it depends on and, since dependency is transitive, also the modules that those modules depend on and so on. So, higher the efferent coupling of a module, harder it is to reuse it.

Note that we are talking about reusing a module and not just copying chunks of code. Code copying is not code reuse.

code copying … comes with a serious disadvantage: you own the code you copy! If it doesn’t work in your environment, you have to change it. If there are bugs in the code, you have to fix them. If the original author finds some bugs in the code and fixes them, you have to find this out, and you have to figure out how to make the changes in your own copy. Eventually the code you copied diverges so much from the original that it can hardly be recognized. The code is yours. While code copying can make it easier to do some initial development; it does not help very much with the most expensive phase of the software lifecycle, maintenance.

I prefer to define reuse as follows. I reuse code if, and only if, I never need to look at the source code (other than the public portions of header files). I need only link with static libraries or include dynamic libraries. Whenever these libraries are fixed or enhanced, I receive a new version which I can then integrate into my system when opportunity allows.

Now, to make my high level component reusable, I need to remove it’s dependencies on low-level modules. This is one of the motivations behind Dependency Inversion Principle put forward by Robert C. Martin in another of his brilliant papers on Design Patterns.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.

This predicament is absurd! It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way.

Moreover, it is high level modules that we want to be able to reuse. We are already quite good at reusing low level modules in the form of subroutine libraries. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

He defines the Dependency Inversion Principle as

a) High level modules should not depend upon low level modules. Both should depend upon abstractions.

b) Abstractions should not depend upon details. Details should depend upon abstractions.

    Here’s an example from the same paper. In the traditional layered design as below, a change in the lowest level Utility Layer can affect the highest level Policy Layer.

    Instead of letting each layer depend directly on the one underneath it, I can make each of the higher level layers use the lower layer through an interface (abstract class) that the actual layer implements (derives from).

    Now none of the higher level layers will be affected if any of the lower level layers change, as long as they keep abiding to their respective interfaces. If I switch to a third party library for any of the lower level layers, I can write an Adapter to make it confirm to its interface, thereby not affecting the higher level layer at all.

    In many simple cases, DI can also be achieved through callbacks. A very common example is when a module provides APIs to allow the application to set its own memory allocation and de-allocation callbacks. The application may do this when it wants to use a heap optimized for small memory allocations, or if it wants to keep track of total memory allocated.

    However, I think there are cases when it’s alright if you don’t follow DIP.

    1. Lower-level module is highly stable. If you know that the lower-level module won’t change much during the life time of the depending module, and you are never going to have to replace it, even when the depending module is reused in another application, there is no harm in depending directly on it.
    2. Lower-level module is highly specific. Again, if you’ll never have to replace the lower-level module with another, you can depend directly on it.
    3. Performance is crucial. Use of abstract classes and virtual functions has a performance penalty. So it’s not advisable for the performance critical parts of the application. However, one can consider using plain function callbacks to achieve DI in such cases, as in the allocation/de-allocation routine example above.

    June 6, 2007

    Why you should learn a new programming language

    Filed under: Dev — harshdeep @ 7:18 am

    As a computer scientist, one must avoid getting stuck with one programming language, even if it’s the “best programming language ever” and you can use it to do everything you’d ever want to. By constraining oneself to a particular language for too long, one starts confusing “what is” with “what should be” and “what can be”.

    I’ve been using C++ for the last 7 years. I had the (primitive) Borland Turbo C++ compiler on my first computer that dad gifted me when I entered NSIT. I fell in love with it immediately and, besides brief forays into Java and VB, I’ve mostly stuck to it since then.

    It’s a wonderful language. I was developing software for desktop and mobile platforms (no web development), and it was sufficient for all my needs. Some of my tasks might have been completed much faster if I had used, say, Perl or Python, but C++ is like a trusted friend whom I’d always approach first. Other options were considered if there was a very significant gain in terms of productivity – significant enough to warrant the learning curve.

    But I don’t think this is the right approach in the long run. I should have gone through the learning curve in many of those situations. An engineer must continuously learn new tools to make himself more productive. Scott Hanselman puts it more directly by saying that you should learn one new language every year.

    I’m now learning ActionScript for my current project which is a Flex/Apollo application. In spite of the suffix “script”, it is a very powerful and flexible language. I learn something interesting every day. Some of the stuff that you can do in ActionScript will never be supported in C++. This doesn’t mean that C++ is archaic compared to ActionScript or that ActionScript has insufficient or unnecessary features. It just means that the two languages are used for different purposes, and have different styles of getting things done.

    A fundamental difference between ActionScript and C++ is that ActionScript is prototype-based while C++ is class-based. A class in ActionScript is internally very different from one in C++. In C++, a class definition is just a blueprint for the objects. In ActionScript, like other prototype-based languages, it is an object in itself and new objects are created by cloning it. This is what the reference says.

    Every class definition is represented by a special class object that stores information about the class. Among the constituents of the class object are two traits objects and a prototype object. One traits object stores information about the static properties of the class. The other traits object stores information about the instance properties of the class and serves as the primary mechanism for class inheritance. The prototype object is a special object that can be used to share state among all instances of a class.

    Look at the XML handling in ActionScript. Thanks to the E4X support, you can use XML as part of your code…

    … and work with it in intuitive ways using little code. For example mXml..name gives a list of names of all employees, and mXml.employee.(age<30).name gives the list of younger ones only. Here is an introduction to E4X in ActionScript.

    There are several other interesting things about ActionScript that will be new to somebody born and brought up with C++. And it’s probably the same with other languages as well. So, even if you don’t have an immediate need to use a new language, I feel it’s worth taking some time out to get your hands dirty with one. It’s fun and chances are that you’ll pick up something fundamental in the process.

    « Newer PostsOlder Posts »

    Blog at WordPress.com.