A side project I'm working on, in the Computer Vision field, is an algorithm which searches images to find a usable color palette for a given tone (low, mid, or high).
My initial thoughts were that it would be significantly easier if the image was converted to HSV color space, instead of working in RGB. If you're unaware, HSV stands for Hue Saturation Value. It works particularly well for this problem, because that is exactly the type of information we want to look at. Its also a much more natural color space to think in, because it's modeled after the Color Wheel.
The procedure for my first attempt was:
This method worked fairly well for some images, but failed for some. The problem was that it wasn't looking at enough color samples. My second attempt was very similar, but pulled 5 samples per line, instead of 1. This worked significantly better, but still failed on some test images.
My third, and most successful attempt was:
Here's one of the tests for the third method. I have a couple ideas to improve it further, which I'll be working on when I get a little more free time.
I've been working on a couple OS X desktop applications, for internal project management. I've worked in Objective-C on and off before, but I really think this is a good time to express my thoughts on Objective-C, as a language.
One thing Objective-C does well, is provide common data structures to use. Unlike plain C, which doesn't have and out-of-the-box ADTs, Objective-C has structures such as maps and lists. Inside Objective-C, this works exceptionally well, even giving very clean mutex locking through @synchronized(var) {..}. The part that feels clunky, is when you try to combine both C and Objective-C with these structures. The language requires keys/values to be a pointers to heap-allocated resources, following its own standard conventions. This means if you have some C structure from a flat C library that you want to import to a list/map, you have to write more boilerplate to wrap those values in one of the NSString/Number objects. At times, this makes it feel like you're working in two separate languages instead of one. If you can stick to straight Objective-C, then it feels much more natural.
Other advantages are that you have access to a wide variety of built-in APIs, which can free up more time to focus on building an application instead of focusing on smaller details.
My gripes are that the language is very "noisy". You'll find the names of some methods ridiculously long, forcing you to break apart what should be a single line of code to several. Just take a look at this delegate method prototype for Outline Views, which you application may or may not need to implement:
- (id)outlineView:(NSOutlineView *)outlineView objectValueForTableColumn:(NSTableColumn *)tableColumn byItem:(id)item;
There are many much worse examples, but I used this one because it actually came up in the project I'm working on. Another issue is some of the APIs Apple has come up with, have later been scrapped in favor of something new, which leads to library/framework fragmentation when dealing with certain things (such as encryption).
Overall, my experience with Objective-C has been positive, with a few minor complaints here and there.