Early Morning Photography

Punch Doggy

Here's an early morning photograph, with my favorite German Shepherd. I have done some post work without messing up with the lighting. Just click through for the high resolution version. This was done without a D-SLR. I like that fact a lot. We call him 'Punch' (after Punch and Jody), and yes there's Judy girl who is tougher to photograph, but will probably make it to my album soon enough.

The Element of Fire

Fire, especially at Night - and a Campfire is so beautiful and dazzling, you love to keep your eyes at it, and you enjoy being near it when its cold. Lighting one in the modern day is rather easy, but fire-light in the camp, as it dances, waxes and wanes and lets in the star-light, is most beautiful - and yet by nature burns you if you're too close.


Camp Fire by Beta

Click to view it in high-resolution, I am no ace photographer, so this is one of my good clicks. 

A Week less ordinary

This week was more fun at work than I'd anticipated. We have finally laid the benchmarks and lines to take one of the products I've been involved with out to the market, engaged a few customers and are already working on revisions. To add to the thrill, there's one more product also in the field where I was involved in redoing an algorithm.

Beyond this, I have been trying to squeeze the best performance out of a CMOS sensor for improved realistic images. It looks like I might have hit some of the physical boundaries of CMOS sensor technology beyond which only smart post-processing could help. I am also set for a trip for my School's Silver Jubilee; set for 23, 24, 25 January. I am hoping to be present from 24 January to keep my presence at work maximal (this being one of my new year resolutions.)

On Cameras and Pictures

This day at work, my boss was down with fever and I was taking up the weekly status review in his stead. It took half the time which was well spent, attendance being thinner than usual. The rest of the day was spent in finding another (sigh!) anomaly with camera images on something we were working on. By the end of the day, we did find an answer to it, but we had created collateral restrictions working on it.

Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.

Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.

As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)

Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)

I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."

So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.

With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.

The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.