| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| manual:sub2r_control_center [2018/01/20 06:27] – [Color Substitution - ''Green screen'' setup] Richard Neumann | manual:sub2r_control_center [2022/04/04 23:32] (current) – external edit 127.0.0.1 |
|---|
| 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 === |
| 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. | 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". This is also known as PRNU or pixel response non-uniformity. 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 G3 will be replaced by the value of (G1+G4)/2. | 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. | **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. |
| {{: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]] |
| | |
