I don't know much about the job market in India, so I can't tell you anything about how "job-oriented" OpenGL is there. I work in the US writing software tools for 3D animators, so I do know something about the field in general.
The first thing I would say is that there are much easier ways to make a living as a programmer than doing graphics and graphics related programming. So I think it is only something you should pursue if you would really like to do that sort of work. If that's the case, and you put in the time to get good at it, my guess is that you will be able to find work doing it. It might be work that pays less than many easier programming jobs. But it might also be very satisfying work.
OpenGL is something that you should definitely learn if you want to do graphics programming. But OpenGL by itself is a very small part of what you need to know to do most jobs that require a lot of OpenGL programming. There are a lot of different domains that involve graphics programming and each has its own set of requirements. So you might want to do some research and find some area that you find particularly interesting, and find out what other things you need to know to be competent in that field.
Just to give you an example from the domain I am working in right now- well, I started working on a project for a small company in May. When I got there I discovered that their basic process was a mess. So I had to set up a dev server, set up version control, and teach the other programmers to use it. I also introduced some rudimentary testing.
Then I spent most of the summer designing some new algorithms (in collaboration with another developer there.) We prototyped the algorithms in Python. At first we worked in 2D, using pygame and openGL. The description of what our algorithms should do came from an animator and was in many ways very vague. We beat our heads against the wall, trying approach after approach, for 3 months. In that time we had to at least skim dozens of academic papers, looking for clues and picking up techniques.
We tried a lot of things, and a lot of the approaches we tried required a lot of computational geometry, and quite a bit of what I would call "applied differential geometry." I'm not really a math whiz, and I can't claim to understand the deeper aspects of differential geometry, but over the years I have learned to fake it a bit, which is a skill of its own. We also used some approaches from optimization theory- linear programming and geometrical programming. And I implemented at least 3 different interpolating splines, and researched quite a few others.
In the end our breakthrough came when we realized that we could treat our geometry as a signal and adapt some DSP (digital signal processing) algorithms to our vector valued domain- that didn't quite work, but my collaborator drew on his experience doing physical simulations and suggested that we iterate the function, and that did work, though it was hideously slow in Python. In the end it took us three months to come up with about 75 lines of Python.
Once we had the 2D case worked out we generalized it to 3D, using a simple 3D library called visual python to visualize our results. The 3D case introduced a lot of complications, but we eventually solved them using some complicated trigonometry, a bit of linear algebra, and a lot of computational geometry.
That done, we moved to Maya (a 3D animation package, and the platform where we will commercialize our work), where I wrote a Python library that provides a DSL that encapsulates a lot of the uglier bits of the API that lets you write Maya plugins. After we adapted our existing code to Maya we found that it needed to be about 1000-2000 times as fast as it was. I am rewriting the expensive bits in ANSI C at the moment, and replacing one function at a time using an FFI (foreign function interface) library called ctypes. This is complicated, as I have to make sure that all of the python structures exist in parallel with the C data structures until I am in a position to dispense with the python data, but it has the advantage that I have a working program after every step. In the end I suspect that even highly optimized C code will not be as fast as we want, and we will push a lot of the work onto the GPU- but I won't do that until the profiler tells me I must.
Once the optimization is done we will have to write a lot of UI components so that animators can actually use our tools. Then we will have to debug, and track bugs from our testers. Then we will have to make installers for Windows, Linux and OS X. I hate death marches, but we would like to ship early this summer, so I imagine I will be working 60-70 hour weeks for a while, 'cause i don't see this getting done by then any other way. And even with long weeks the schedule may slip- this happens when you set out to improve the state of the art.
I've given you a very long reply, and one that might seem at first to not be responsive to your question. But I wanted to give you an idea of what kind of work you might wind up doing in a few years if you decide to specialize in graphics now. And I also wanted to point out that a lot of "graphics" programming really draws on a lot of disciplines. In my case, at least, the OpenGL part is trivial compared to the rest of the work.
If you want to be good enough at this stuff that you will always have work, because very few other people can do what you can, the key is to know the basics well, so that you can be flexible. If you look at the laundry list of things I had to be able to do to do the job I've been doing this year- well, I had to learn the specifics on the fly. The only way to be able to that quickly enough is to know the basic patterns that recur over and over in software and algorithms. So be hungry, and try to have at least a broad overview of as many areas of computing as you can.
I didn't know the specifics of the DSP algorithms we adapted before this, but I knew they existed, and I knew what they did, in a general way. I had never used ctypes before this, but I have used other ffi libraries. I experimented with simulated annealing at one point (though we wound up not using it.) I sure didn't know the details of that, but I was aware of it as an optimization technique.
So yes, go ahead and learn OpenGL, if you want to do this kind of programming. But OpenGL is a detail- one library out of an infinite number of possible libraries. Learn the substance too. Algorithms, math, good development practices, the ability to skim hundreds of pages of API docs in a day, not with the idea of memorizing them, but with the idea of having a mental index of them, the ability to make sense of doctoral dissertations where it wasn't in the interests of the candidate to be clear- you'll need all these skills.
I'd also highly recommend that you learn a language like Python that is a bit more flexible than C++. Graphics programmers tend to use C++ as C with classes anyway, as they don't want to pay for the machinery of idiomatic C++. Python is often way too slow for production, but for testing out ideas you really need something more flexible than C with classes. You will learn OpenGL a lot faster if you use something like pygame to experiment with it than if you use C++. If you are adventurous you could do as someone above suggests and learn a Lisp- if I had had my druthers we would have prototyped in some Lisp but it wasn't practical in this case.