From: Milton Aupperle <milton@outcastsoft.com>

Date: July 14, 2005 12:46:38 PM MDT

To: Astro_IIDC@yahoogroups.com

Subject: Re: [Astro_IIDC] just wishing


Hi Alan;


On 14-Jul-05, at 11:29 AM, Alan Friedman wrote:

Hi Milton -


Thanks for filling in this info. I didn't notice that the RGB data came from a Canon DSLR.


The lumenera cameras are significantly more expensive than most of the other choices (at least twice the cost of my DMK21BF04 - 10X my Unibrain board camera). I think the users (and there are a bunch - including Damian Peach) who have bought the camera through Paolo in Italy are using an application called Streampix to access a bit depth greater than 8 bits/pxl? 


I went through Streampix info and it doesn't say if it does more than 8 bits or not. It looks like they don't use the WDM drivers, so its possible they support more than 8 bits. The Lumenera cameras use a 10 bit A/D converter actual and most of the "up scale" Firewire cameras do 10 or 12 bit. My Flea is 12 bit.


In case people are wondering, the difference in bits a camera  can deliver means the following:


-a 8 bit camera can deliver 256 shades of gray or 16,777,216 colors. This is what your Mac displays, known as millions of colors.


-a 10 bit camera can deliver 1024 shades of gray or 1,073,741,824 colors.


- a 12 bit camera can deliver 4096 shades of gray or 68,719,476,736 colors


- a 16 bit camera can deliver 65536 shades of gray or 281,474,976,710,656 colors.


The difference is that the more shades you get the more likely you'll record those photons on the CCD, rathe than it being lost in the background noise or simply lost because of the granularity of the CCD.



And the data is usually delivered in a 16 bit word of data, scaled up as appropriate. I say usually, because a few cameras pack four 12 bit values together to create a 48 bit or 6 byte pixel package to save bandwidth - which is a PITA to support under OXS and even worse under x86 (SSE has no Permute type Altivec functions for bit/bytes/word swapping data).


I have been toying with the idea of trying my DMK camera and RGB filterwheel on some brighter planetary nebulae - when I get over my laziness and do a real polar alignment some night I will share the results.


It should work pretty well.


I have to mention that I have had many emails from DMK users wondering what software I use with my camera - seems they are finding the Windows driver included with the cameras from the Imaging Source to be difficult to use for astronomical applications. Don't think I have persuaded too many to move to a Mac platform yet though...


Yep - which is part of the quandary I am in currently since WWDC 2005.


It took me a week to move Astro IIDC from CodeWarrior to XCode 2.1 (it's all C code - no fancy classes or other encumbrances) and XCode as a development system sucks even more than MS's development system does when I last used it in 2001/2002.  After investigating all the performance options with XCode 2.1, Astro IIDC takes a minimum 25% performance hit using Apple XCode 2.1 over the same build with Code Warrior 9.5. This means your performance has dropped by a minimum of 25%, your battery life will be reduced by at least 25% and your CPU runs 25% hotter than it needs to because Apple is incompetent and can not build a decent compiler. With the $6 billion in the bank, they could have bought or licensed a best of breed PPC compiler for a few million dollars - but Steve would have to admit that Apple is a big part of the problem with performance on PPC - and that isn't going to happen as "Steve is never wrong".


I also have hundreds of thousands of lines of code and months of 12+ hour 7 day per week work to do to bring Astro IIDC to OSX x86. Unlike Apple, we hand optimize and performance tune our code, so it's tied tightly to PPC architecture (i.e. endianness, utilizing all 32 integer and fpu registers in the CPU and using Altivec as much as possible) and now I throw it all away. Despite Steve's hype, Apples market share is not growing at all and Apple sold more Macs in the first quarter of 2000 than they announced yesterday (which makes me wonder if the increase sales over last year is mainly because people are upgrading their Macs after 5 years of use and are obsoleted).


So my quandary is  if I have to re-write all this code for x86, do I take that extra step and go WinTel (30 times Apples market share ) or MacTel to cover these costs? I have limited resources, will be forced to buy a minimum of four x86 OSX boxes (probably $15,000 CDN) for testing purposes and so I have to make some hard choices over the next month or so about what is best for me - as Apple could care less about it's developers.


Lastly regardless of what I decide, I consider a x86 a version for all our software a "new product" and none of the unlock keys are going to work on MacTel or WinTel systems - you'll be re-buying it again.


TTYL..


Milton J. Aupperle

President

ASC - Aupperle Services and Contracting

Mac Software (Drivers, Components and Application) Specialist

#1005 - 815 14th Avenue. S.W.

Calgary Alberta Canada T2R0N5

1-(403)-229-9456

milton@outcastsoft.com

www.outcastsoft.com