DPChallenge: A Digital Photography Contest You are not logged in. (log in or register
 

DPChallenge Forums >> Hardware and Software >> Photography Software: I Wrote Some
Pages:  
Showing posts 1 - 25 of 53, (reverse)
AuthorThread
11/15/2010 08:37:18 PM · #1
Hey folks!

It's that time again... I've just submitted the latest version of my handy exposure calculator Expositor to the iTunes App store! I expect it'll be approved in about a week. In fact, it's already in the queue with the status "pending an Apple release" (as opposed to "waiting for review"), so it may go live as soon as tomorrow, when Apple releases something, whatever that is!

I took everyone's feedback and was able to add all of the best suggestions. It's written to support iOS 4.2, with updated, high-res art for retina displays, and even has a brand new super-size version for the iPad!

Expositor 2.0 also includes a much larger slide rule for more flexibility:

- EVs from 16 to -6
- ISOs from 3 to 25600
- F-Stops from 0.5 to 512
- Shutter speeds from 1/8000 second to 8 hours
- Exposure compensation from -42 to 41. Lunacy!

With ranges like those, it should be sure to satisfy even freaks using a pinhole camera to shoot the moon through obsidian.

The whole interface has been streamlined to behave smoothly no matter what you're doing, and the new iPad version animates everything fluidly! I even crammed more detailed scene information into both the iPad and retina display versions. It's a major update, to be sure!

So, should I add a depth calculator next? Can you think of any other features that would be nice to add? Help me build and awesome v2.1 and maybe I'll toss you a free copy! ;)

Here's the iPad version:





Sexy, huh? I'd love your feedback on the visual design, even if you don't own it. :)

Yes, I have the geekiest hobbies ever...

Message edited by author 2010-11-16 00:59:30.
11/15/2010 09:47:16 PM · #2
Make one for Android!!!
11/15/2010 10:55:46 PM · #3
Looking good!
11/15/2010 11:28:38 PM · #4
It's beautiful. Makes me wish I had an iPad... DOF calculator for sure in the next iteration.

It would be nice also if it had an idiot-proof filter function, where you could specify the filters you're adding and get the new exposure in actual data, not a filter factor. In other words, add an 8x and a 4x ND filter stacked with a polarizer, and this is your new exposure...

That's a fairly esoteric function, but one of the tougher ones to figure out if you haven't internalized filter factors. And when you stack a lot of filters, the camera's light meter isn't always spot on anymore.

If you're intending this thing to be used with film, reciprocity calculations for the most popular films would be good :-)

R.
11/16/2010 12:24:37 AM · #5
Originally posted by EL-ROI:

Make one for Android!!!


Buy me Android hardware! ;)
11/16/2010 12:46:27 AM · #6
Originally posted by Bear_Music:

It's beautiful. Makes me wish I had an iPad... DOF calculator for sure in the next iteration.

It would be nice also if it had an idiot-proof filter function, where you could specify the filters you're adding and get the new exposure in actual data, not a filter factor. In other words, add an 8x and a 4x ND filter stacked with a polarizer, and this is your new exposure...

That's a fairly esoteric function, but one of the tougher ones to figure out if you haven't internalized filter factors. And when you stack a lot of filters, the camera's light meter isn't always spot on anymore.

If you're intending this thing to be used with film, reciprocity calculations for the most popular films would be good :-)

R.


Oh my god, a filter function would be awesome! Like, a filter factor calculator, you select your filters and it fills in the exposure compensation for you automatically! Genius!

It could even work in both directions... pick a compensation and it could tell you how many 1/2/4/8 NDs you need, or you list what you have and try to find the closest/fewest filter combo.

I know I can never do the math in my head! I wish they'd just label filters by how many stops they block. And I'll just have to assume a standard polarizer is 1 stop. But yeah, lovely idea.

I've been balking on implementing a DOF calculator even though I have all the algorithms/data I need (people put JavaScript versions online all the time and you simply can't copyright the data or algorithms, hehe) because I want to represent it graphically... actually blurring an image to represent a scene... and that's complicated. I also want to make it all touchy-feely like the exposure calculator slide rule, with big spinning dials for desired near/far distances, stuff like that... oof, it's a lot of work to get it to the polish of a 'real' iPad app. A touch interface is a very different paradigm from a keyboard and mouse!

Reciprocity is the lowest on my list... that comes way after a sun angle/direction calculator.

Ergh, what I need is staff. :)

Anyone know obj-c and enjoy math? Or just enjoy math with the ability to explain it to a former math whiz who hated math so much he let that capability completely atrophy, shrivel up, and drop off the moment it was not required to graduate?

Notice the completely geometric nature of the exposure calculations in Expositor! Woo, no math! Well, except for the whole animating everything behind the scenes kind of math that I just describe and let the computer carry out for me.
11/16/2010 01:11:43 AM · #7
I also kind of want to add audio to the ISO/F-Stop roller part of the slide-rule, so it ticks every time it passes a detent, and audibly reminds you it's changing the calculation. That seems hard to get the timing right for. Who knows? It's the kind of thing I just have to slog my way through and fake and hope I accidentally didn't fake in hindsight, haha. I have an idea how to do it, but I always have an idea... and half the time they're angst laden forays into the wilderness.

That's why I procrastinate a lot. :D
11/16/2010 02:37:12 AM · #8
Originally posted by Mousie:

Originally posted by EL-ROI:

Make one for Android!!!


Buy me Android hardware! ;)


no need for hardware !! :-)

//developer.android.com/sdk/index.html

Message edited by author 2010-11-16 02:37:24.
11/16/2010 02:49:58 AM · #9
Originally posted by goc:

Originally posted by Mousie:

Originally posted by EL-ROI:

Make one for Android!!!


Buy me Android hardware! ;)


no need for hardware !! :-)

//developer.android.com/sdk/index.html


You can't seriously be suggesting a seasoned professional programmer should go to market without testing on actual hardware?

No way! Simulators only get you so far! :D
11/16/2010 03:51:00 AM · #10
I apologize in advance for my ignorance but can you explain to me what is the purpose of the application? Does not the camera do all this calculations for me ? when my shutter speed is too fast/slow I see the Over/Underexposure indicator in plus or minus a couple of units, after that I correct to the desire exposure, am I right ? WHy do I want to know the right number coming out of the application? Even though the applications have differen scenarios of light ( bright day ligh, hazy and so on) there might be other conditions affection my exposure, lets say reflectivity of light by the surrounding objects next to my target, or the amount of light passing through the forest or things like that. am I right of thinking that all these factor could affect and then the given exposure number coming out of the application could lead me wrong?

Having this application mean that i will need to have my computer/ ipad all the time to set the right exposure. is this "right" exposure just for post processing purposses ?

these question might be stupid I dont know, but I wonder everytime the same when I see all these calculators for right F-stop, Shutter speed and so on on the internet. the usability of this calculators gets me always confused. What aboout the camera model. DO ALL the sensors ( chosen by the different camera brands ) behave the same to apply the same calculator for all camera models?

thank you for you answers!
11/16/2010 10:22:42 AM · #11
The next progression for a "seasoned professional programmer" would be to extend this app to convert the iPhone camera into an (incident) light meter.

Great job so far, looks professional and seasoned...

11/16/2010 10:46:48 AM · #12
You don't need Android software, the SDK can mimic any device on screen.

But anyway, I have a Desire, I can test anything you send :P

Message edited by author 2010-11-16 10:47:41.
11/16/2010 12:23:42 PM · #13
Originally posted by THOR95:

I apologize in advance for my ignorance but can you explain to me what is the purpose of the application? Does not the camera do all this calculations for me ? when my shutter speed is too fast/slow I see the Over/Underexposure indicator in plus or minus a couple of units, after that I correct to the desire exposure, am I right ? WHy do I want to know the right number coming out of the application? Even though the applications have differen scenarios of light ( bright day ligh, hazy and so on) there might be other conditions affection my exposure, lets say reflectivity of light by the surrounding objects next to my target, or the amount of light passing through the forest or things like that. am I right of thinking that all these factor could affect and then the given exposure number coming out of the application could lead me wrong?

Having this application mean that i will need to have my computer/ ipad all the time to set the right exposure. is this "right" exposure just for post processing purposses ?

these question might be stupid I dont know, but I wonder everytime the same when I see all these calculators for right F-stop, Shutter speed and so on on the internet. the usability of this calculators gets me always confused. What aboout the camera model. DO ALL the sensors ( chosen by the different camera brands ) behave the same to apply the same calculator for all camera models?

thank you for you answers!


No worries, I appreciate a healthy dose of skepticism. Now for your questions:

The purpose of this application is to calculate exposures for using a camera manually, which is what I do. When you shoot manually and are good at it, I've found that it speeds up your workflow by removing variables from the process... namely the different exposure estimates produced by different cameras when pointing at different subjects.

A camera has a reflected light meter. They suck. Reflected light meters always try to make your scene a medium exposure, or about 18% gray. This is great if you're shooting concrete or a gray card, but fails miserably when shooting white or black subjects, and you have to remember to compensate for the way your camera will habitually over or underexpose these scenes. That's why everyone always says to add an exposure compensation of +1 when shooting snow! Worse, the angle the light is reflecting off a subject can make the exposure vary wildly... glare, matte surfaces... if it has a lot of angles reflecting different quantities of light, it can be hard to pick the right settings to make the whole scene look good.

They make incident light meters that report an exposure based on the light falling on your subject, not the light bouncing off of it. They are a lot better than reflected light meters, and won't get fooled by the color, material, or angle of your subject. I have one, it rocks! However, you have to go stand right next to your subject to take a reading... kind of a pain when it's not right next to you, and it might not even be accessible! You'll get a lot more accurate results with one of these, but you always have to carry it around and use it, and it's not doing anything you can't train yourself to do (or calculate based on scene) fairly accurately.

Once you know approximately how bright a certain scene is, there's no need to re-measure it. You can just look up or remember the EV, and do the math to get all possible combinations of settings that will work to expose it correctly... or look up all the combinations with a tool like Expositor and avoid the math/conversions.

In practice, using a calculator like this I get a consistent, well-exposed series of images within half a stop of a perfect exposure that take way less individual post-processing, since manual camera settings produce the same result under the same lighting again and again, no matter what part of the overall scene I aim at. Perfecting them is as easy as mass-adjusting the whole mess once I'm in Lightroom. If I want exposures accurate to within a 1/10th of a stop in camera, I bust out my incident light meter, but RAW files have enough latitude that this is almost never necessary. In fact, it's only through the use of light meters and manual calculators that I was able to see what a difference a proper exposure made compared to my cameras' guesses... I started getting tons more detail and color saturation, it even became fun for me to shoot on overcast days, a look I had always struggled with.

You are right that reflected light will influence an exposure, but not by enough to completely throw you off in practice unless the conditions are very unusual, and you can of course compensate for this manually, or with the calculator itself! If you know there's about an extra stop of light bouncing onto your scene because it's next to something white, dial it in and continue shooting. If the sun goes down and you come back to shoot in moonlight, the compensation will still work. You're never really going to have more than an extra stop of light even if your subject is sitting in a white box under full sun. Just set the EC to -1 or -2/3 and continue shooting normally. Remember, this is a calculator not a magic exposure device, you still have to input the values yourself. The scene descriptions are only an guide, you have to pick the right EV based on your understanding of the scene. (And the iPad version has a scene for 'under rainforest canopy' BTW!)

Tossing a question back at you, why would you need to have your computer/iPad set to the right exposure all the time? I don't understand this question. The calculator has no effect on your camera or computer. You use it to calculate an exposure, input those settings into your camera, then forget about it unless you want to look up a different combination that produces the same results. By the time it gets to your computer it's already locked in and all you can do is adjust it up and down a bit, if you're shooting RAW. You use it before you shoot your picture. :)

To answer the last question, as long as your camera isn't a piece of crap, it *will* expose the same with the same settings as other cameras. EV/ISO/F-Stop/Speeds are industry standard, and cameras that deviate... well... they deviate! They under or overexpose in reference to the standard. If your camera misbehaves, it should do so consistently, and you can compensate for that in the Expositor with the exposure compensation setting just like you would when using in-camera auto-exposure while shooting a bright subject... you know the camera will goof it up so you tell it not to. You know your camera is weird, so you tell the calculator. It's the same thing, just a lot more consistent with Expositor since you're not dealing with a reflected light meter. And you only need to figure it out once per device or lens or whatever.

For example, I shoot a lot of macro, and my extension tubes make me lose some of the light, sometimes over a stop! They came with a chart that shows exactly how much is lost, depending on how many tubes I'm stacking. When I slap some on there, I look at the chart, set the exposure compensation to cancel out the loss of light, and get great exposures all day, even when the sun goes behind clouds or I walk into the woods, changing the EV... I don't have to worry about the tubes any more, just the overall light of the scene.

You're also missing a bunch of the other benefits of tools like this... honestly I don't even use it much anymore unless I want to do something unusual... I've used it enough that the relationships are becoming stuck in my head. Seeing them represented visually on a slide rule makes this stuff feel natural and easier to memorize. Bright sunny day? ISO 200, F16, 1/250s. I know it now because I've seen it over and over and over.

What about when you're stacking a ton of ND filters on your gear? I could not tell you from memory what the same scene would need with an 2ND and 8ND filter without thinking a bit... but I can add the loss of light to my calculator and not think about it... and maybe eventually I'll memorize those combinations too! Rote memorization has it's uses, and a good calculator facilitates this. :)

Oh man, way too much info!

Part of the reason I'm so hyper about exposure is from seeing the difference that using a calculator and an incident light meter has made to my own work. I feel crippled without them these days... spoiled by previous accurate exposures... so much so that I wanted something I could always carry in my pocket at all times, just in case. I first made myself some paper calculators... but they kind of sucked, lacked range, and were fragile... I figured I can program... why not make one for my phone? And here we are. :)

Hey, your questions aren't bad... heck, you've given me a reason to explain why everyone here should want a copy. ;)
11/16/2010 12:32:42 PM · #14
Originally posted by pointandshoot:

The next progression for a "seasoned professional programmer" would be to extend this app to convert the iPhone camera into an (incident) light meter.

Great job so far, looks professional and seasoned...


Thanks for the suggestion! I've actually looked into this before, and unfortunately it's a no-go. The sensors in the iPhone are wildly innacurate... and deviate significantly from phone to phone, even within the same model. Worse, there's no good way to read the values from the hardware in a way that makes sense for the calculations required... and the optics are much too sensitive to changes in glare, light on the lens, scratches on the lens, even the ambient temperature... it's just way too many factors to reliably get an exposure calculation to within 1/2 stop of the 'real' value. This is my guess as to why there are none available in the store today. :)

There's a reason incident meters are spendy, and have those cute plastic domes and such... accuracy. You'd get a more precise result using a manual exposure calculator like Expositor than an iPhone-based incident meter, IMO. Maybe a math supergenius could come up with some clever sampling-over-time agorightm to get closer to an accurate result with iPhone hardware... but even then I'd imagine you'd need extensive, repeated calibration using a gray card for every iOS device you use under every condition you're using it. The just aren't consistent enough.

Bummer!
11/16/2010 12:47:02 PM · #15
Originally posted by dd1989:

You don't need Android software, the SDK can mimic any device on screen.

But anyway, I have a Desire, I can test anything you send :P


So can iOS development tools... XCode has quite excellent simulators... but as anyone who's spent time in the biz knows, software test is no replacement for a proper suite of hardware. The idea of releasing without proper test gives me the heebie-jeebies.

For example, my trippy particle system toy PixelSwarm had to restrict certain features on the iPhone 3GS because of a detail of their OpenGL ES backbuffer implementation. Works great in the simulator and on the iPhone 4/iPad... and fails utterly on the 3GS. Oh well! I would have never found it until after shipping if I didn't have all three to test on, and that just looks bad.

You have proposed a decent alternative however... maybe if I can get some interested parties to act as an informal QA department for Android versions I'd be more motivated. I've been programming in Java for over half a decade... it's one of the easiest languages there is. I'd have to look at the SDK in detail to see how simple it would be to port the animating behaviors, the only complex part of this project. The calculator? That's just sliding some images back and forth. :)

Heck, I might even give someone the source code or a tutorial if they wanted to port it for me and share the profits. I must make a whopping... 3 times $1.99 - 30%... $4.17 a day on sales! Who wants their two extra candy bars a day in profits? :)
11/16/2010 12:56:37 PM · #16
What's the programming language on iOS, is it objective C? - And what about Android, isn't that Java?
11/16/2010 01:14:00 PM · #17
Originally posted by Mousie:

... maybe if I can get some interested parties to act as an informal QA department ...

I thought that was an industry-standard procedure called "beta-testing" ... you should be having someone besides yourself testing it -- even if on your own hardware -- as they are almost sure to try things you wouldn't.

"It is impossible to make anything foolproof, as fools are so ingenious."
-H.D. Thoreau
11/16/2010 02:40:57 PM · #18
Originally posted by Mousie:

Originally posted by pointandshoot:

The next progression for a "seasoned professional programmer" would be to extend this app to convert the iPhone camera into an (incident) light meter.

Great job so far, looks professional and seasoned...


Thanks for the suggestion! I've actually looked into this before, and unfortunately it's a no-go. The sensors in the iPhone are wildly innacurate... and deviate significantly from phone to phone, even within the same model. Worse, there's no good way to read the values from the hardware in a way that makes sense for the calculations required... and the optics are much too sensitive to changes in glare, light on the lens, scratches on the lens, even the ambient temperature... it's just way too many factors to reliably get an exposure calculation to within 1/2 stop of the 'real' value. This is my guess as to why there are none available in the store today. :)

There's a reason incident meters are spendy, and have those cute plastic domes and such... accuracy. You'd get a more precise result using a manual exposure calculator like Expositor than an iPhone-based incident meter, IMO. Maybe a math supergenius could come up with some clever sampling-over-time agorightm to get closer to an accurate result with iPhone hardware... but even then I'd imagine you'd need extensive, repeated calibration using a gray card for every iOS device you use under every condition you're using it. The just aren't consistent enough.

Bummer!


Bummer indeed... that means my plastic iDome [Patent Pending] is iWorthless.

OK... howz about this:
1. use gps to get location
2. get % of cloud cover at that location (query weather service database)
3. get angle of sun at that location (from whatever database)
4. use data from #2 and #3 to calculate correct EV value.
5. eat candy bar

11/17/2010 03:50:02 PM · #19
Originally posted by JH:

What's the programming language on iOS, is it objective C? - And what about Android, isn't that Java?


iOS is in C and Obj-c. Obj-C is profoundly weird, but cute and powerful.

Android is, yes, written in Java.

I'm fluent in both! :)
11/17/2010 03:57:57 PM · #20
Originally posted by GeneralE:

Originally posted by Mousie:

... maybe if I can get some interested parties to act as an informal QA department ...

I thought that was an industry-standard procedure called "beta-testing" ... you should be having someone besides yourself testing it -- even if on your own hardware -- as they are almost sure to try things you wouldn't.

"It is impossible to make anything foolproof, as fools are so ingenious."
-H.D. Thoreau


Who says I'm not? :D

I have a number of friends I force to test my apps on real hardware, often theirs. Convincing them to allow me to add their devices to my provisioning profiles isn't always easy, but I paired the request with an early update to whatever beta OS was in the pipeline at the time. A multi-tasking iPad is so much nicer then a non-multi-tasking iPad, it's a good trade! :)

Unfortunately, in the App Store environment customer-facing beta testing is not very feasible... there's no convenient parallel distribution channel to push out early releases to volunteers. you have to explicity set up an Ad-Hoc distribution channel with explicit opt-in, collecting device IDs, stuff like that.

But come on, you think I'd release an app without mad testing? Seriously? :D It's just that almost all my friends are iPhone and iPad users. It's Silicon Valley after all.
11/17/2010 03:59:59 PM · #21
Originally posted by pointandshoot:


Bummer indeed... that means my plastic iDome [Patent Pending] is iWorthless.

OK... howz about this:
1. use gps to get location
2. get % of cloud cover at that location (query weather service database)
3. get angle of sun at that location (from whatever database)
4. use data from #2 and #3 to calculate correct EV value.
5. eat candy bar


That is already on the list, a sun angle/direction calculator. I doubt the local cloud coverage information is enough to predict EV accurately, but you could certainly do it based on time of day, outdoors, in the open!
11/17/2010 08:34:26 PM · #22
Originally posted by Mousie:

Originally posted by JH:

What's the programming language on iOS, is it objective C? - And what about Android, isn't that Java?


iOS is in C and Obj-c. Obj-C is profoundly weird, but cute and powerful.

Android is, yes, written in Java.

I'm fluent in both! :)


Actually, Android is written in a combination of Assembly, C, C++ and Java. It is also possible to write your own programs in all those languages, although Java is the "default" and easiest to start off with.

Some things are only possible (or at least much easier) to do on the Java-side, such as audio playback. Other things make more sense to do on the "native" (C/C++) side, such as manipulation of large arrays, tight loops with lots of calculation etc. Some things will even make sense to implement in Assembly, such as operations that can benefit from the NEON extensions on some of the ARM processors.
11/17/2010 09:13:49 PM · #23
Originally posted by wiesener:

Some things are only possible (or at least much easier) to do on the Java-side, such as audio playback. Other things make more sense to do on the "native" (C/C++) side, such as manipulation of large arrays, tight loops with lots of calculation etc. Some things will even make sense to implement in Assembly, such as operations that can benefit from the NEON extensions on some of the ARM processors.


That's why I say that Android is in Java... you need to use the highest level language to get the full suite of functionality.

It's just like Obj-C in iOS... you can write a lot of code in raw C or even lower level languages, but to access some of their higher-level APIs you MUST use Obj-C... they only make them available in that syntax.

For example, all my mathematically intense, OpenGL ES-based particle system code in my iOS app PixelSwarm is written in pure C using simple structs, inline methods, and raw memory buffers... NOT objects that need to be constantly allocated and destroyed or that send messages to each other to interpret and execute. Because, you know, it needs to be snappy! The UI itself is all in Obj-C, however.

Even so, I'd consistently say that you develop for the iPhone in Obj-C, regardless of how I've personally optimized certain sections of my own logic.

And Assembler? Why not just say that's how you can program everything, and call it a day? Why bother calling it out? You're being a bit pedantic, here. ;)

P.S. You forgot Ruby and Python, both of which can be used to implement Android apps. (JRuby/JPython)

And web apps using JavaScript and DHTML techniques.

And Flash.

And you could write an online back-end that drives major parts (or all) of your app's behavior in any language supported by your server, using the device as a thin client.

See? I can be pedantic too. But if I were to send someone off to learn Android development, I'd tell them to go lean Java, not the rest. Which is what I did. :)
11/17/2010 09:27:44 PM · #24
Originally posted by EL-ROI:

Make one for Android!!!


Yeah that would be awesome.
11/18/2010 07:52:35 AM · #25
Originally posted by Mousie:

Originally posted by wiesener:

Some things are only possible (or at least much easier) to do on the Java-side, such as audio playback. Other things make more sense to do on the "native" (C/C++) side, such as manipulation of large arrays, tight loops with lots of calculation etc. Some things will even make sense to implement in Assembly, such as operations that can benefit from the NEON extensions on some of the ARM processors.


That's why I say that Android is in Java... you need to use the highest level language to get the full suite of functionality.

It's just like Obj-C in iOS... you can write a lot of code in raw C or even lower level languages, but to access some of their higher-level APIs you MUST use Obj-C... they only make them available in that syntax.

For example, all my mathematically intense, OpenGL ES-based particle system code in my iOS app PixelSwarm is written in pure C using simple structs, inline methods, and raw memory buffers... NOT objects that need to be constantly allocated and destroyed or that send messages to each other to interpret and execute. Because, you know, it needs to be snappy! The UI itself is all in Obj-C, however.

Even so, I'd consistently say that you develop for the iPhone in Obj-C, regardless of how I've personally optimized certain sections of my own logic.

And Assembler? Why not just say that's how you can program everything, and call it a day? Why bother calling it out? You're being a bit pedantic, here. ;)

P.S. You forgot Ruby and Python, both of which can be used to implement Android apps. (JRuby/JPython)

And web apps using JavaScript and DHTML techniques.

And Flash.

And you could write an online back-end that drives major parts (or all) of your app's behavior in any language supported by your server, using the device as a thin client.

See? I can be pedantic too. But if I were to send someone off to learn Android development, I'd tell them to go lean Java, not the rest. Which is what I did. :)


If I were to send someone off to learn Android development I'd tell them to start off with Java as well, but I would still let them know that there is more to the equation. By comparing iOS as being objective C and C, with Android as being only Java, you are implying that Android is a less advanced platform than iOS, which obviously isn't true. I just wanted to correct that impression.

As for Assembly, I specifically call it out because you need it (or some similarly archaic compiler intrinsics) if you want to benefit from the CPU extensions available in the newest ARM NEON-based processors (That goes for iOS as well, by the way). Think of it like MMX/3DNOW/SSE2-extensions for desktop CPUs. Using those extensions you can do stuff like multiply and add on 16 variables simultaneously, which will obviously give a tremendous speed increase for software where those sorts of operations are relevant - video playback being a common example.

Of course you are right that there are a bunch of other higher-level languages that can be used as well, specifically anything that compiles to Java bytecode, and I guess I should have mentioned those for completeness. My goal, however, was simply to inform people that low-level (and performance-critical) development is actually possible on Android platforms as well. There seems to be a general misconception that Android is slow and sluggish ("cause it's Java-based, you know"), and I don't want people to perpetuate that myth. Is that pedantic of me? Maybe.

Message edited by author 2010-11-18 07:57:10.
Pages:  
Current Server Time: 04/16/2024 02:31:19 PM

Please log in or register to post to the forums.


Home - Challenges - Community - League - Photos - Cameras - Lenses - Learn - Prints! - Help - Terms of Use - Privacy - Top ^
DPChallenge, and website content and design, Copyright © 2001-2024 Challenging Technologies, LLC.
All digital photo copyrights belong to the photographers and may not be used without permission.
Current Server Time: 04/16/2024 02:31:19 PM EDT.