| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| manual:sub2r_control_center [2018/01/20 06:02] – Richard Neumann | manual:sub2r_control_center [2022/04/04 23:32] (current) – external edit 127.0.0.1 |
|---|
| ''Gain'', a.k.a. "global gain" is applied (additive) universally to all the 3 channels. | ''Gain'', a.k.a. "global gain" is applied (additive) universally to all the 3 channels. |
| |
| It is worth mentioning that increasing the ''Gain'' (either global or per-channel) **always** adds noise. There many types of noise that are inherent in CMOS image sensors. The value of a pixel is derived by the number photons collected by the pixel over a given time. There is even noise from the light source. A CMOS pixel will generate dark current noise which is an electrical charge generated in the absence of photons. Conversion of photons to an electrical current is known as the Quantum Effect, the process of which will generate noise. Gain is analogous to volume in audio. Turning the volume up will make your music louder but it will also amplify the "hiss" or white noise in the background. The same is true for color channel or global gain. It will increase the intensity of the color but it will also increase the noise. To optimize the signal to noise ratio it is always advantageous to increase exposure first before pushing ''Gain''. | It is worth mentioning that increasing the ''Gain'' (either global or per-channel) **always** adds noise. There are many types of noise that are inherent in CMOS image sensors. The value of a pixel is derived by the number photons collected by the pixel over a given time. There is even noise from the light source. A CMOS pixel will generate dark current noise, which is an electrical charge generated in the absence of photons. Conversion of photons to an electrical current is known as the Quantum Effect, the process of which will also generate noise. Gain is analogous to volume in audio. Turning the volume up will make your music louder, but it will also amplify the "hiss" or white noise in the background. The same is true for color channel or global gain. It will increase the intensity of the color, but it will also increase the noise. To optimize the signal to noise ratio, it is always advantageous to increase exposure first before pushing ''Gain''. |
| |
| ''Exposure'' is a sensor-defined number that doesn't have an easy-to-describe way of being converted into exposure timing without taking into consideration internal sensor's characteristics (like a current internal clock speed, or sub-windowing, or an externally-driven global shutter) and is beyond the scope of this document((You may be able to find the needed information on the image sensor manufacturer's technical documentation. Please contact the manufacturer directly for assistance. On some models of sensor chips the ''Exposure'' value is interpreted in the context of the currently selected video mode (resolution, windowing, FPS) and may additionally depend on other bit modes set in other registers. For all these reasons the number presented for ''Exposure'' is just that - an abstract number in a range, supported by the sensor chip.)). | ''Exposure'' is a sensor-defined number that doesn't have an easy-to-describe way of being converted into exposure timing without taking into consideration internal sensor's characteristics (like a current internal clock speed, or sub-windowing, or an externally-driven global shutter) and is beyond the scope of this document((You may be able to find the needed information on the image sensor manufacturer's technical documentation. Please contact the manufacturer directly for assistance. On some models of sensor chips the ''Exposure'' value is interpreted in the context of the currently selected video mode (resolution, windowing, FPS) and may additionally depend on other bit modes set in other registers. For all these reasons the number presented for ''Exposure'' is just that - an abstract number in a range, supported by the sensor chip.)). |
| The front-facing LED can be programmed to emit colors in 8-bit 3-channel RGB color space (24 bits total), though due to technical limitations some of the colors cannot be presented accurately - which is something only people with an exceptional color perception would ever notice. | The front-facing LED can be programmed to emit colors in 8-bit 3-channel RGB color space (24 bits total), though due to technical limitations some of the colors cannot be presented accurately - which is something only people with an exceptional color perception would ever notice. |
| |
| The design is currently utilizing a CREE 3 element LED part number CLVBA-FKA-CAEDH8BBB7a363. | The design is currently utilizing a [[http://www.cree.com/|Cree]] 3 element LED part number ''CLVBA-FKA-CAEDH8BBB7a363''. |
| |
| Dominant Wavelength | ^ Color ^ Dominant wavelength ^ Luminous intensity (mcd) @IF=20mA ^ |
| Red 619-624nm | | Red | 619-624nm | 224-560 | |
| Green 520-540nm | | Green | 520-540nm | 280-900 | |
| Blue 460-480nm | | Blue | 460-480nm | 90-355 | |
| |
| Luminous Intensity (mcd) @IF=20mA | The LED is mounted on the camerboard. There is a [[https://www.bivar.com/|BIVAR]] PLPC combination light pipe and diffuser mounted on the front plate inline with the LED. The light pipe helps to reduce the perceived intensity and increases the viewing angle. |
| Red 224-560 | |
| Green 280-900 | |
| Blue 90-355 | |
| | |
| The LED is mounted on the camerboard. There is a BIVAR PLPC combination light pipe and diffuser mounted on the front plate inline with the LED. The light pipe helps to reduce the perceived intensity and increases the viewing angle. | |
| |
| **N.B.** | **N.B.** |
| Total number of remembered "defective" pixels is limited to 65536. | Total number of remembered "defective" pixels is limited to 65536. |
| |
| Generally you are way better off using a provided GUI for the same operation, described in the section [[#DPC calibration]] further down. | Generally you are way better off using a provided GUI for the same operation, described in the section [[#DPC - Defective Pixel Calibration]] further down. |
| |
| === Reset from SPI Flash === | === Reset from SPI Flash === |
| Besides the self-explanatory ''Exit'' options this ''File'' menu provides the ability to save/load a subset of the camera's state parameters which provides an easy way to clone the settings or to save/restore presets for various sets of environment: per lighting equipment/setup, indoor/outdoor, bright/dim, etc | Besides the self-explanatory ''Exit'' options this ''File'' menu provides the ability to save/load a subset of the camera's state parameters which provides an easy way to clone the settings or to save/restore presets for various sets of environment: per lighting equipment/setup, indoor/outdoor, bright/dim, etc |
| |
| ==== Green screen setup ==== | ==== Color Substitution - ''Green screen'' setup ==== |
| {{:manual:frankie-0f.png?nolink|Green screen enhancer setup}} | {{:manual:frankie-0f.png?nolink|Green screen enhancer setup}} |
| |
| One of the most exciting out-of-the-box features of the camera is its Green Screen enhancer. Given a range of colors the camera will automatically replace them with a set "flat" color on a fly, making it extremely robust to actually use the image substitution techniques during your streaming! | One of the most exciting out-of-the-box features of the camera is its color substitution Green Screen enhancer. Given a range of colors the camera will automatically replace them with a set "flat" color on the fly, making it extremely robust to actually use the image substitution techniques during your streaming! |
| |
| === Enable chroma key enhancer === | === Enable chroma key enhancer === |
| |
| |
| ==== DPC calibration ==== | ==== DPC - Defective Pixel Calibration ==== |
| With literally millions of individual sensor elements, each measuring in mere microns, running at ultra-high clock speeds, it is virtually inevitable to have errors((this is true if you consider the price/performance ratio, of course. Surely one could make a fault-tolerant sensor, but its price would be prohibitively high and not fit for consumer market)). Some errors are more annoying (read: visually noticeable) than others and random pixels with bright values fall squarely into that category. | With literally millions of individual sensor elements, each measuring in mere microns, running at ultra-high clock speeds, it is virtually inevitable to have errors((this is true if you consider the price/performance ratio, of course. Surely one could make a fault-tolerant sensor, but its price would be prohibitively high and not fit for consumer market)). Some errors are more annoying (read: visually noticeable) than others and random pixels with bright values fall squarely into that category. |
| |
| Many factors can introduce those sporadic fluctuations, even the rarely thought about ones like a very benign heating of the sensor's elements. | Many factors can introduce those sporadic fluctuations, even the rarely thought about ones like a very benign heating of the sensor's elements. The pixel performance will also change over time. |
| |
| During power cycle the SUB2r camera performs auto-calibration and tries to figure out which pixels "misbehave". For best results the camera cap has to be fully closed which (naturally) is rarely the case in its day-to-day use. | During power cycle the SUB2r camera performs auto-calibration and tries to figure out which pixels "misbehave". This is also known as PRNU. For best results the camera cap has to be fully closed which (naturally) is rarely the case in its day-to-day use. |
| |
| To that end a function is provided that allows to perform the re-calibration without power cycling the camera. Video streaming has to be stopped for the calibration to be done properly. | To that end a function is provided that allows to perform the re-calibration without power cycling the camera. Video streaming has to be stopped for the calibration to be done properly. |
| Detecting too many pixels may degrade the final image quality as it will result in a (though relatively tiny) loss of details. | Detecting too many pixels may degrade the final image quality as it will result in a (though relatively tiny) loss of details. |
| |
| There's a limit of a total of 65536 detected pixels. | There's a limit of a total of ''65536'' detected pixels. |
| |
| {{:manual:frankie-0j.png?nolink|DPC dialog}} | {{:manual:frankie-0j.png?nolink|DPC dialog}} |
| |
| Once the calibration is finished a new ''Detected defective pixels'' total will be displayed so you can judge whether the result is acceptable to you. | Once the calibration is finished a new ''Detected defective pixels'' total will be displayed so you can judge whether the result is acceptable to you. |
| | |
| | Prior to de-Bayering or demosaicing, the conversion of RGGB to RGB, the processor will replace the value of a known defective pixel with the average value of the previous and subsequent pixel of the same color by row. In the case of ''R1'',''G1'',''R2'',''G2'',''R3'',''G3'',''R4'',''G4'',''R5'',''G5'' if ''G3'' is determined to be a defective pixel, then ''G3'' will be replaced by the value of ''(G1+G4)/2''. |
| | |
| | **NOTE:** The OVT10823 sensor is a native 4K chip which is down sampled by binning and skipping method to 1080p. Currently a separate DPC is required for 4K and 1080p. |
| |
| ==== Sensor registers' dump ==== | ==== Sensor registers' dump ==== |
| {{:manual:frankie-0m.png?nolink|Sensor register's dump}} | {{:manual:frankie-0m.png?nolink|Sensor register's dump}} |
| |
| When debugging or just monitoring the image sensor directly one might need to see which values are changing between two points in time. This little handy window provides you the ability to tale a snapshot of the current register values in a range of addresses and then, at a later time, ''Refresh range'' to see what's the current state. Or, if you have the ''Show changes only'' enabled it will just show what's changed. | When debugging or just monitoring the image sensor directly one might need to see which values are changing between two points in time. This little handy window provides you the ability to take a snapshot of the current register values in a range of addresses and then, at a later time, ''Refresh range'' to see what's the current state. Or, if you have the ''Show changes only'' enabled it will just show what's changed. |
| |
| Clicking either ''Full snapshot'' or specifying too wide of a range of addresses could cause the sensor chip to timeout and become unresponsive. Powercycling the camera should bring it back to life ;-) | Clicking either ''Full snapshot'' or specifying too wide of a range of addresses could cause the sensor chip to timeout and become unresponsive. Powercycling the camera should bring it back to life ;-) |
| {{:manual:frankie-0r.png?nolink|FW upgrade}} | {{:manual:frankie-0r.png?nolink|FW upgrade}} |
| |
| Once the camera is in your hands that doesn't mean we've stopped improving it. On the contrary - the development continues with lots of new and exciting features in the pipeline. This dialog box provides a way for you to install newer versions of the firmware onti your SUB2r camera (or downgrade to earlier version, if needed). | Once the camera is in your hands that doesn't mean we've stopped improving it. On the contrary - the development continues with lots of new and exciting features in the pipeline. This dialog box provides a way for you to install newer versions of the firmware onto your SUB2r camera (or downgrade to earlier version, if needed). |
| |
| The main ''Firmware upgrade fox DX3 and FPGA'' dialog box provided current version info for both the FX3 and the FPGA (these two modules run different code, of course). | The main ''Firmware upgrade for DX3 and FPGA'' dialog box provided current version info for both the FX3 and the FPGA (these two modules run different code, of course). |
| |
| For either one you could chose to pick up only the code that is "at least in X development cycle", where "X" ranges from ''Alpha'' to ''Bugfix'' and defaults to whatever you set in [[#Preferences]], like ''Evaluation''. You can also chose to use a ''Local file'' if you build your own binaries with your custom functionality: | For either one you could chose to pick up only the code that is "at least in X development cycle", where "X" ranges from ''Alpha'' to ''Bugfix'' and defaults to whatever you set in [[#Preferences]], like ''Evaluation''. You can also chose to use a ''Local file'' if you build your own binaries with your custom functionality: |
| * If you are feeling particularly confident (or adventurous) you can disable the "are you sure?" warning popup when running unsafe commands. You will be asked again (ONE LAST TIME!) and then you are on your own - the warranty doesn't cover damage caused by using the tool in this manner | * If you are feeling particularly confident (or adventurous) you can disable the "are you sure?" warning popup when running unsafe commands. You will be asked again (ONE LAST TIME!) and then you are on your own - the warranty doesn't cover damage caused by using the tool in this manner |
| * Auto-refresh interval is used, for example, in the ''Sensor'' tab for monitoring some of the changes in image sensor's registers when enabling the ''Auto-refresh'' | * Auto-refresh interval is used, for example, in the ''Sensor'' tab for monitoring some of the changes in image sensor's registers when enabling the ''Auto-refresh'' |
| * Whenever a single command or a batch of commands takes longer than this specified amount of time a ''Meditating...'' dialog box pops up to show progress: {{ :manual:frankie-meditation.png?nolink |Meditaion...}} | * Whenever a single command or a batch of commands takes longer than this specified amount of time a ''Meditating...'' dialog box pops up to show progress(({{:manual:frankie-meditation.png?nolink|Meditaion...}})) |
| * When upgrading firmware you can change the earliest release cycle to consider for your new image. Normally you are going to be just fine with the default ''Release candidate'' setting, but if you are an early adopter you might want to change that to ''Evaluation'' or even earlier than that. As always - the earlier the code is in a release cycle, the more risk there is that it would have bugs and other unintended behavior. | * When upgrading firmware you can change the earliest release cycle to consider for your new image. Normally you are going to be just fine with the default ''Release candidate'' setting, but if you are an early adopter you might want to change that to ''Evaluation'' or even earlier than that. As always - the earlier the code is in a release cycle, the more risk there is that it would have bugs and other unintended behavior. |
| ==== Technical Info ==== | ==== Technical Info ==== |
| |
| The ''Version'' information includes the date and time of the build((in ''GMT'' time zone)) in the following format: ''YYMMDD_hhmm'' and uses a 24-hour clock. | The ''Version'' information includes the date and time of the build((in ''GMT'' time zone)) in the following format: ''YYMMDD_hhmm'' and uses a 24-hour clock. |
| | |
| | ==== Color Grading setup ==== |
| | [[Color Grading shortcuts]] |
| | |
