Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

CMOS sensors for EAA

  • Please log in to reply
132 replies to this topic

#1 Relativist

Relativist

    Cosmos

  • *****
  • topic starter
  • Posts: 8151
  • Joined: 11 Oct 2003
  • Loc: OC, CA, USA

Posted 28 August 2017 - 01:49 PM

While I understand that most CMOS sensors out there are SoC, so that in theory all cameras with the same sensor should have similar performance. I note the 'amp glow reduction' that was added to some IMX224 based cameras shortly after their introduction. Since these sensors are digital, analog circuits are not going to play a role generally. So then the question becomes, what does matter for a good CMOS sensor implementation for EAA use?

#2 ccs_hello

ccs_hello

    Voyager 1

  • *****
  • Posts: 10237
  • Joined: 03 Jul 2004

Posted 28 August 2017 - 05:07 PM

Curtis,

 

Yes, those CMOS SoC (system on chip) image sensor systems are all digital and (almost) 100% self-contained.

Hehe, actually 99%.

 

Smart guys such as Dr. Qiu (the QHY fame) had figured out few tricks to squeeze out a bit more, some undocumented SoC features and some pure electronic tricks (to push beyond spec.)

These are dark secrets or real IPs, but not hard to learn.

Others who play in the astro-camera field soon follow suit.  Security cam mfrs usually don't care about these niche features.

 

What does matter:

- lower thermally generated noise (some mistakenly call it amp-glow), even in long exposure

- push max exposure time beyond what is documented in SoC's datasheet

 

Others are trivial ones but often overlooked by "video" camera/security cam mfgs:

- not even bother to investigate into any form of long exposure (security cam industry does not like smeared images/fuzzy faces)

- do not switch SoC out of movie/video mode into (multiples of) one-shot image-taking mode

- do not understand some image sensors have HCG mode and (clueless thus not) willing to take advantage of it

 

Clear Skies!

 

ccs_hello



#3 mclewis1

mclewis1

    Thread Killer

  • *****
  • Posts: 18674
  • Joined: 25 Feb 2006
  • Loc: New Brunswick, Canada

Posted 28 August 2017 - 06:37 PM

Some "differentiators" ...

 

- while it was more prevalent with CCD sensors there is still some grading of CMOS sensors (you obviously would like less warm/hot pixels).

- firmware levels, is the SoC using different firmware levels (can be very hard for end users to determine however). Different firmware is often tied to revision levels of the chipset, so that can make things a bit easier.

- case design. How effective is the case at dissipating heat, how are the connectors affixed, etc.

- optical window characteristics (if present what is the bandpass?)


  • ccs_hello likes this

#4 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 01:29 PM

The SoC output is completely digital.

 

As css_hello points out there are some SoC control "tricks" you can use for example to reduce amp glow but these are not solutions per se and don't constitute IP (Intellectual Property). You cannot file patents or claim novelty for these. Also these "tricks" are trivial to implement.

 

Also these tricks don't substantially change the overall performance of the camera. They are usually about controlling the SoC in certain ways (sometimes in ways unanticipated by the manufacturer). The whole idea of a SoC (and business model behind it)  is to provide consistent performance to all device manufacturers with minimal R&D / integration effort.

 

Also as far as I am aware Sony does not sell different "grades" of CMOS sensors. Not sure where this comes from and if this is true.

 

The SoC also does not have firmware (in the sense we understand it here on these forums) as it does not have its own control. The camera's firmware interacts with and controls the SoC i.e. tells it what modes to function in, how to take the exposure, how to output the data etc.

 

In my opinion the only way CMOS camera manufacturers can truly differentiate (beyond marketing claims) are:

 

1. Mechanicals - i.e. camera body design, thermal characteristics and cooling, sensor chamber, optical window etc.
2. Software - E.g. drivers, support and timely bug fixes, bundled capture and//or live stacking software



#5 Relativist

Relativist

    Cosmos

  • *****
  • topic starter
  • Posts: 8151
  • Joined: 11 Oct 2003
  • Loc: OC, CA, USA

Posted 29 August 2017 - 03:13 PM

Wasn't it determined that the reduced 'amp glow' 'hack' was a desirable feature for EAA? Was our conclusion about that somehow wrong?

#6 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 04:18 PM

Wasn't it determined that the reduced 'amp glow' 'hack' was a desirable feature for EAA? Was our conclusion about that somehow wrong?

Sorry don't understand your comment. Yes, of course it is desirable. Not sure where I said it was not.

 

It is not a hack per se but rather required modifying the control logic of the SoC. Not that complicated to do and no unique or patentable IP here.

 

Another very important point to note is that you can only apply this trick to the 224 because the SoC supports powering down certain blocks during exposure. The camera manufacturer can do nothing about Amp Glow if the SoC does not support it. Also this feature is available to all camera manufacturers who use the SoC. It is just control logic.

 

I hope this helps answer your question.


Edited by Astrojedi, 29 August 2017 - 05:02 PM.


#7 jimthompson

jimthompson

    Apollo

  • *****
  • Posts: 1087
  • Joined: 06 Oct 2009
  • Loc: Ottawa, Canada

Posted 29 August 2017 - 04:57 PM

From a camera architecture stand point, does nothing sit in between the CMOS SoC and the software?  For commonly used image processing tasks (noise reduction, colour correction, debayering, etc.) it would make sense to me to have a digital signal processor in line.  Such a hardware based processor would give a camera manufacturer ample opportunity to contribute their own special features and highly affect the output without putting dependence on software.

 

Regards,

 

Jim T.



#8 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 05:14 PM

From a camera architecture stand point, does nothing sit in between the CMOS SoC and the software?  For commonly used image processing tasks (noise reduction, colour correction, debayering, etc.) it would make sense to me to have a digital signal processor in line.  Such a hardware based processor would give a camera manufacturer ample opportunity to contribute their own special features and highly affect the output without putting dependence on software.

 

Regards,

 

Jim T.

Jim,

 

In CMOS SoCs the output is digital. There is no way for the camera manufacturer to insert itself between the analog to digital conversion which is where CCD camera manufacturers have added value traditionally.

 

Once you have a digital image yes, you can do processing on it but then at that point it is irrelevant whether the processing is happening within the camera or on a PC. There is nothing special you can do within the camera that you cannot do in software. It is exactly the same.

 

The only advantage I can see of processing digital output within the camera is if you want to provide customers an integrated PC free experience. But in doing so the costs rise disproportionately to the functionality provided especially for such small volumes. You just end up with a crippled and very expensive device. I used to make such product design decisions on a daily basis so very familiar with the cost benefit analysis.

 

The most cost effective and powerful solution is to write software on the PC to complement the camera. This has the benefit of being able to leverage the full processing capability of the PC for more advanced image processing and stacking. It also much easier and cost effective to introduce and distribute updates and new functionality.

 

Best

Hiten


Edited by Astrojedi, 29 August 2017 - 05:21 PM.

  • Don Rudny likes this

#9 mikefulb

mikefulb

    Surveyor 1

  • *****
  • Posts: 1649
  • Joined: 17 Apr 2006

Posted 29 August 2017 - 06:33 PM

Is the extra magic some companies have added to deal with amp glow (ASI224 for example) software or hardware?



#10 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 06:35 PM

Is the extra magic some companies have added to deal with amp glow (ASI224 for example) software or hardware?

See my post above. It is not magic. It is a fix to the SoC control circuitry. The SoC has to support it otherwise the camera manufacturer can do very little.



#11 OleCuss

OleCuss

    Vanguard

  • *****
  • Posts: 2279
  • Joined: 22 Nov 2010

Posted 29 August 2017 - 08:01 PM

See my post above. It is not magic. It is a fix to the SoC control circuitry. The SoC has to support it otherwise the camera manufacturer can do very little.

 

 

 

You need to understand that those of us (like myself) who are not nearly as conversant in the subject as are you and a very few others, that answer is not clear.  It may be very clear to you and to others with your level of sophistication, but not to folk like myself.

 

When you say that it is a fix to the SoC control circuitry, that doesn't actually tell folk like me whether it is a change in the circuitry of the sensor, whether there is circuitry which is added to the sensor prior to signal reaching the computer, or whether it is a driver/software fix which commands the SoC control circuitry to behave in a different manner.

 

I'm actually pretty sure that we are not altering the circuitry of the sensor (I suspect that would be far beyond anything a manufacturer would attempt and may be technically impossible without destroying the sensor/chip.

 

I also rather doubt that there is additional circuitry being added to the sensor although that is far more likely than altering the sensor circuitry.

 

So my best guess is that the driver is used to configure the SoC to behave differently?

 

I know that you are giving great explanations, but to a certain extent you are speaking a different language.


Edited by OleCuss, 29 August 2017 - 08:02 PM.


#12 Brian_S

Brian_S

    Vostok 1

  • -----
  • Posts: 158
  • Joined: 09 Dec 2010
  • Loc: West Lafayette, IN

Posted 29 August 2017 - 08:08 PM

Found an interesting article on CMOS-based cameras:

 

https://www.linkedin...ernard-genoud-1

 

One point he raises is the following: "Does performance vary between different camera types when they both have the same CMOS sensor? Most spec sheets for cameras prominently feature the sensor inside. Gather enough of those spec sheets together and you‘ll quickly determine which different models are using the same sensor. All the more surprising that those different cameras will often stack up very differently when it comes to image quality, interface options and firmware features."

 

Might be worth a read.

 

Best,

 

Brian



#13 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 09:14 PM

 

See my post above. It is not magic. It is a fix to the SoC control circuitry. The SoC has to support it otherwise the camera manufacturer can do very little.

 

 

 

You need to understand that those of us (like myself) who are not nearly as conversant in the subject as are you and a very few others, that answer is not clear.  It may be very clear to you and to others with your level of sophistication, but not to folk like myself.

 

When you say that it is a fix to the SoC control circuitry, that doesn't actually tell folk like me whether it is a change in the circuitry of the sensor, whether there is circuitry which is added to the sensor prior to signal reaching the computer, or whether it is a driver/software fix which commands the SoC control circuitry to behave in a different manner.

 

I'm actually pretty sure that we are not altering the circuitry of the sensor (I suspect that would be far beyond anything a manufacturer would attempt and may be technically impossible without destroying the sensor/chip.

 

I also rather doubt that there is additional circuitry being added to the sensor although that is far more likely than altering the sensor circuitry.

 

So my best guess is that the driver is used to configure the SoC to behave differently?

 

I know that you are giving great explanations, but to a certain extent you are speaking a different language.

 

Point taken. I will try to be clearer.

 

SoC control circuitry = Circuits that control the Sensor SoC and tell it what to do. Not part of the sensor SoC. Part of camera design. No special sauce in circuits. Cannot do amp glow control if the SoC does not support it.


  • OleCuss and roelb like this

#14 A. Viegas

A. Viegas

    Mercury-Atlas

  • *****
  • Posts: 2988
  • Joined: 05 Mar 2012
  • Loc: New York City/ CT

Posted 29 August 2017 - 09:24 PM

Found an interesting article on CMOS-based cameras:

https://www.linkedin...ernard-genoud-1

One point he raises is the following: "Does performance vary between different camera types when they both have the same CMOS sensor? Most spec sheets for cameras prominently feature the sensor inside. Gather enough of those spec sheets together and you‘ll quickly determine which different models are using the same sensor. All the more surprising that those different cameras will often stack up very differently when it comes to image quality, interface options and firmware features."

Might be worth a read.

Best,

Brian


Intereting post, thanks Brian

The point grey marketing people who wrote that paper essentially confirm everything that Hiten (Astrojedi) has been saying. Bottom line the CMOS SoC are Not differentiated in and of themselves. Rather... the advantages of choosing a good manufacturer are:

1. Design of casing for heat and overall ruggedness
2. Firmware to take advantage of sensor capabilities
3. Quality control of testing of cmos sensors and choosing those with fewer defects
4. Good assembly and manufacturing practices
5. Customer support

And last one which the article does not mention... Price


Al
  • elpajare likes this

#15 Brian_S

Brian_S

    Vostok 1

  • -----
  • Posts: 158
  • Joined: 09 Dec 2010
  • Loc: West Lafayette, IN

Posted 29 August 2017 - 09:26 PM

Al,

 

Indeed. I found it an interesting read that summarizes the issues well.

 

All the best,

 

Brian



#16 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 29 August 2017 - 09:41 PM

Also to add to what Al said. These are usually not that hard to get right for a camera manufacturer with some experience. Marketing departments often release such papers to gain credibility and imply they do it better without actually saying so.



#17 ccs_hello

ccs_hello

    Voyager 1

  • *****
  • Posts: 10237
  • Joined: 03 Jul 2004

Posted 29 August 2017 - 09:42 PM

There are really dark hacks in few mfgs' CMOS astro-imagers to squeeze out a bit more juice.

For most of us (high-gain EAA, not using extra long exp time), the added benefit is less important/considered software-fixable anyway.

To protect their innovations, I can only hint that (they are indeed few tricks less well known)...



#18 jimthompson

jimthompson

    Apollo

  • *****
  • Posts: 1087
  • Joined: 06 Oct 2009
  • Loc: Ottawa, Canada

Posted 30 August 2017 - 08:35 AM

...

 

Once you have a digital image yes, you can do processing on it but then at that point it is irrelevant whether the processing is happening within the camera or on a PC. There is nothing special you can do within the camera that you cannot do in software. It is exactly the same....

If this were true, there would be no third party video cards for your PC.  There is plenty of advantage being able to take care of signal manipulation tasks in camera as it off loads the PC CPU, and can be made to work faster than through software.  Not being forced to use a high end PC to use the camera would be a big advantage, especially in a security situation where you have dozens of cameras monitored from a single station.  High frame rates are also an advantage, certainly for those among us who do solar system imaging.

 

Regardless of whether the processing occurs on the camera or on the PC, there is a lot that the camera manufacturer can do at this stage to affect the final output.  Since, as many here have said, software is now an integral part of the camera hardware these days, I don't see how anyone can say there can be no significant difference in the performance of two cameras with the same CMOS sensor.

 

Regards,

 

Jim T.


  • will w and Dwight J like this

#19 OleCuss

OleCuss

    Vanguard

  • *****
  • Posts: 2279
  • Joined: 22 Nov 2010

Posted 30 August 2017 - 08:57 AM

I think his statement was limited to the moment you have the digital image.  Lots happens before you get to that stage (including manufacturing/design stages).



#20 A. Viegas

A. Viegas

    Mercury-Atlas

  • *****
  • Posts: 2988
  • Joined: 05 Mar 2012
  • Loc: New York City/ CT

Posted 30 August 2017 - 09:39 AM

...

Once you have a digital image yes, you can do processing on it but then at that point it is irrelevant whether the processing is happening within the camera or on a PC. There is nothing special you can do within the camera that you cannot do in software. It is exactly the same....

If this were true, there would be no third party video cards for your PC. There is plenty of advantage being able to take care of signal manipulation tasks in camera as it off loads the PC CPU, and can be made to work faster than through software. Not being forced to use a high end PC to use the camera would be a big advantage, especially in a security situation where you have dozens of cameras monitored from a single station. High frame rates are also an advantage, certainly for those among us who do solar system imaging.

Regardless of whether the processing occurs on the camera or on the PC, there is a lot that the camera manufacturer can do at this stage to affect the final output. Since, as many here have said, software is now an integral part of the camera hardware these days, I don't see how anyone can say there can be no significant difference in the performance of two cameras with the same CMOS sensor.

Regards,

Jim T.
Hi Jim

I think you are mixing analogies here. PC video cards come in many varieties with significant hardware differences.

As for CMOS. The point grey marketing paper makes it clear they think they can add value in the ways I pointed out in the prior post. At the margin I suppose improvement in heat dissipation due to case design or better firmware can significantly add differentiating value. But what Hiten is saying is that the root output is digital from the SoC and that output is the same from the cmos sensor regardless if it's housed in a mallincam, qhy, zwo or point grey box. Now once the signal leaves the chip there is plenty a manufacturer can do to improve the final signal that reaches your pc where it again can be modified. Think of it this way:

Cmos sensor output. = Same. Regardless of label on box
Box and internal electronics. = some potential improvement. But hard to gauge or know the value proposition to paying premium price for the label on the box
Firmware/software = most significant differentiator. Easier to determine price/performance quality. E.g. Sharpcap/starlight vs toupsky for instance.


Al

Edited by A. Viegas, 30 August 2017 - 09:40 AM.


#21 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 30 August 2017 - 09:40 AM

 

...

 

Once you have a digital image yes, you can do processing on it but then at that point it is irrelevant whether the processing is happening within the camera or on a PC. There is nothing special you can do within the camera that you cannot do in software. It is exactly the same....

If this were true, there would be no third party video cards for your PC.  There is plenty of advantage being able to take care of signal manipulation tasks in camera as it off loads the PC CPU, and can be made to work faster than through software.  Not being forced to use a high end PC to use the camera would be a big advantage, especially in a security situation where you have dozens of cameras monitored from a single station.  High frame rates are also an advantage, certainly for those among us who do solar system imaging.

 

Regardless of whether the processing occurs on the camera or on the PC, there is a lot that the camera manufacturer can do at this stage to affect the final output.  Since, as many here have said, software is now an integral part of the camera hardware these days, I don't see how anyone can say there can be no significant difference in the performance of two cameras with the same CMOS sensor.

 

Regards,

 

Jim T.

 

The PC cards do a lot of signal processing (e.g. outputting to VGA, HDMI etc) but the primary reason that graphics processing is implemented in hardware is due to speed and not because it cannot be done in software. It is just excruciatingly slow in software because it runs on general purpose hardware.

 

Once again... once you have a digital image the processing after that can be done in camera firmware or in software... makes very little difference.

 

Sure a camera manufacturer can differentiate... but like I said in my earlier post which you obviously did not read... that differentiation is software based like SX's SLL or Atik's Infinity software. Or by implementing mechanicals better or form factor based.

 

As I said above there is value in integrating some of this functionality into the camera especially if you want to provide customers a PC free experience. But that leads to a very limited and very expensive experience.

 


Edited by Astrojedi, 30 August 2017 - 10:02 AM.


#22 jimthompson

jimthompson

    Apollo

  • *****
  • Posts: 1087
  • Joined: 06 Oct 2009
  • Loc: Ottawa, Canada

Posted 30 August 2017 - 10:38 AM

The PC cards do a lot of signal processing (e.g. outputting to VGA, HDMI etc) but the primary reason that graphics processing is implemented in hardware is due to speed and not because it cannot be done in software. It is just excruciatingly slow in software because it runs on general purpose hardware.

 

 

Once again... once you have a digital image the processing after that can be done in camera firmware or in software... makes very little difference.

 

Sure a camera manufacturer can differentiate... but like I said in my earlier post which you obviously did not read... that differentiation is software based like SX's SLL or Atik's Infinity software. Or by implementing mechanicals better or form factor based.

 

As I said above there is value in integrating some of this functionality into the camera especially if you want to provide customers a PC free experience. But that leads to a very limited and very expensive experience.

 

I apologize if it seems I am beating this to death but the general inconsistency really bothers me.  Let me try to back up and lay out my thoughts more clearly:

 

With regards to cameras that use CMOS sensors, there is an argument that has been put forth that because of the system-on-chip nature of these sensors there cannot possibly be any significant performance difference between different cameras with the same sensor.  However it is also agreed that there are many components that make up a camera:

 

- CMOS sensor

- sensor board & off sensor controller

- digital signal processor

- power and output boards

- casing design

- firmware & PC drivers

- PC software

- etc.

 

For the above argument to be true (ie. no significant performance difference between cameras with the same CMOS sensor) then it would also have to be true that all the items above listed below the sensor must have no impact on camera performance.  I'm sorry but I just can't believe that is the case.  In light of the small percentage of the physical package made up by the sensor I firmly believe there is a lot of opportunity for a camera manufacturer to inject their own IP to produce a camera with performance different than their competitors.  In terms of how this applies to Mallincam, I don't see how it is possible for anybody here to know with certainty one way or another that there is none of Rock's IP inside the digital cameras he sells.  Arguing for or against is moot, so let's stop talking about it.  The only information that is relevant are actual observations by users.

 

Regards,

 

Jim T.



#23 Dwight J

Dwight J

    Gemini

  • *****
  • Posts: 3241
  • Joined: 14 May 2009
  • Loc: Lethbridge, Alberta, Canada

Posted 30 August 2017 - 10:52 AM

That was my point Jim in the locked thread; differences can be seen by users and even then due to the many variables, the only way to really tell is a side by side comparison by the same user under the same conditions.  That is where the rubber meets the road.  Given the higher price for the Mallincam, if they are assembled by them there may be fewer QA issues.  Company Seven seems to do alright charging more for Celestron scopes despite no parts being different.  I don't see a particular bias towards them for doing the same thing, should there prove to be no difference in performance.  



#24 Relativist

Relativist

    Cosmos

  • *****
  • topic starter
  • Posts: 8151
  • Joined: 11 Oct 2003
  • Loc: OC, CA, USA

Posted 30 August 2017 - 10:53 AM


Wasn't it determined that the reduced 'amp glow' 'hack' was a desirable feature for EAA? Was our conclusion about that somehow wrong?

Sorry don't understand your comment. Yes, of course it is desirable. Not sure where I said it was not.

It is not a hack per se but rather required modifying the control logic of the SoC. Not that complicated to do and no unique or patentable IP here.

Another very important point to note is that you can only apply this trick to the 224 because the SoC supports powering down certain blocks during exposure. The camera manufacturer can do nothing about Amp Glow if the SoC does not support it. Also this feature is available to all camera manufacturers who use the SoC. It is just control logic.

I hope this helps answer your question.

Well it was sort of by exclusion, since such was not included in the list you had previously. Anyway, from memory, people were told to send their cameras back to get the 'amp glow reduction' feature added, which implies a hardware element.

I would also think that the overall qc procedures and selection of electronic components could make a difference in robustness of a particular camera. Engineering a decent optical window and cooling would also be important.

#25 Astrojedi

Astrojedi

    Soyuz

  • *****
  • Posts: 3785
  • Joined: 27 May 2015
  • Loc: SoCal

Posted 30 August 2017 - 11:13 AM

I really feel I am being attacked on this thread by vested interests for stating scientific fact. I and our engineering teams work with these sensor SoCs all the time. This is my field of work.

 

The Sensor SoCs are designed to produce very consistent output. Of course you can screw up the implementation but I don't see evidence of that with any of the other camera manufacturers.

 

Jim: "With regards to cameras that use CMOS sensors, there is an argument that has been put forth that because of the system-on-chip nature of these sensors there cannot possibly be any significant performance difference between different cameras with the same sensor.  However it is also agreed that there are many components that make up a camera:"

 

Jim, sorry but when did I say this? You have either missed my earlier posts or just choosing to ignore them. There is of course differentiation possible but just not how you described it earlier. As I explained above you can primarily differentiate in 1. Mechanicals and 2. software. Both of these make a big difference. Just see SX's SLL software and Atik's Infinity software. Or the cooling and mechanical performance of FLI's cameras.


Edited by Astrojedi, 30 August 2017 - 11:43 AM.



CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics