|
|
gain en offset.png (70,917 bytes) alleen gain.png (153,663 bytes) |
|
|
Hello Han, thank you to look at this problem. I need a precision what "After a reset of CCDCiel " exactly meant. Restarting or reinstalling the program? deleting the configuration directory? The presence of offset in the driver is checked after the camera connection in cu_ascomcamera function CheckOffset. It return True if the InterfaceVersion is greater than 3, and all the Ascom method Offset, OffsetMin, OffsetMax do not raise an exception. Normally the Ascom driver for the 1600 is the same than for other ZWO camera? I want to be sure the latest is installed from ZWO because at the time of the availability of the 1600 the offset was not supported by Ascom and ZWO take a lot of time to add it after Interface version 3 was published. Also there is still some complication with an offset setting in the config file that remain from the old settings. I look to remove that now and simplify the offset detection. |
|
|
Here are the logs. I can't find anything interesting. |
|
|
The reset was done closing CCDCiel and restart of CCDCiel. I have now installed the latest ZWO drivers. Strangly now the camera driver offset setting seems to be doing nothing. So I can't tell if the offset is set by CCDCiel because offset in the drivers seems doing nothing with the latest ZWO driver. In the old driver the background changed significantly. I do not think the offset is of any importance for this camera. The only thing of importance is a reliable gain setting. I will check with my simulator if the gain and offset are communicated with the simulator. |
|
|
I released that I have to test it with ASCOM first. So I checked the latestest nightly build with my own Touptek camera. The gain is adjustable and it works. The offset field is not visible. I installed the latest Touptek driver but that did not change it. My normal gain is 100. The hint indicates a range 100 to 10000 which seems correct for my camera. Is the hint updated with the value read from the camera? A empthy field results in -32768 (due to the Tspinedit I assume) A value 0 seems to do nothing. Outside the valid range? Both the Touptek and ZWO driver settings are not updated with the CCdciel setting. This is a problem for the suppliers but making checking the setting difficult. Would it not be better to log the setting from the driver. So for my camera, Set gain at 100 with a "put". Then read it with a "get" and update the CCdCiel Tedit value accordingly and log it in the CCdCiel log? So If I try an value outside the range it would return the valid value from the driver. Is the offset field not visible because Touptek is not supporting it? Would an option to allow entering a blank be an option to disable the setting and rely on the driver settings? This could also be the default for users updating CCdCiel. Once something is entered, send a "put" to the camera and receive a "get" to update the Tedit. |
|
|
I make the cleanup I wanted to do after the removal of the option to hide the gain. https://github.com/pchev/ccdciel/commit/af80e50463d19c146dbf5c2ea3c11c42a7be0914 This will be in tomorrow morning build. More data are now directly from the camera and for a new profile it take the current driver settings for gain and offset. It is possible to reset this values by setting both the preview and capture gain to 0 before to connect the camera, if necessary I can add a better way to do that. The spinedit min,max are now set with the driver min,max values, not only the hint. You can check the current value with a script. Put the following content in a file named test.js , replace the driver name, run with from a terminal cscript test.js driver = "ASCOM.Simulator.Camera"; var cam = new ActiveXObject(driver); WScript.StdOut.WriteLine("Gain=" + cam.Gain); WScript.StdOut.WriteLine("Offset=" + cam.Offset); |
|
|
I do more testing this morning, installing first a clean CCDciel version 0.93 without gain display, then upgrading to the last 0.95. This all work as expected, after upgrading to 0.95 it take the default gain/offset from the driver. After changing the gain/offset for a preview the script from my previous post show the expected modified values. If you try that with the new Ascom simulator be careful you must first enter the setup to activate the gain and offset with a numeric range, they are disabled by default. |
|
|
Thanks, yes taking the original gain/offset from the driver is important for the transition. I'm currently implementing an adjustable offset it in my own simulator. Once implemented I will test it with CCDCiel for both Ascom (via a bridge) and Alpaca. |
|
|
I have tested the functionality with my simulator and it looks all good. >>More data are now directly from the camera and for a new profile it take the current driver settings for gain and offset. Seen it working for 0.93 to 0.95, >>It is possible to reset this values by setting both the preview and capture gain to 0 before to connect the camera This did not work for me. The fields are not visible in the camera tab before connection. Only in the guide camera tab. It is good that now the gain and offset can be set in CCDCiel itself. That is easier for users. For me they never change but I assume some users want to experiment with the gain to get a very tiny benifit is any. But is that the case for the offset? Wouldn’t it be better to place the camera offset in the “Edit > Preferences > Camera” menu, using a layout similar to the sensor properties? I would prefer having an indication of the reported Ascom value electronsperadu after camera connection. That is the essential important value. So something like using a Tlabel to display "e-/adu=1.011". Behind or under gain value? |
|
|
Yes I think it work as expected in all the case now. I make a small change so the gain/offset for slewing and autofocus also use initially the default from the camera. I also fix a probably rare case where the gain was not recorded in the FITS header if getting the offset raise an exception. It is good if Gerard can test with tomorrow version. I also never change the gain/offset for my capture. I think this is more useful for people that image under heavy light pollution. Normally the offset need to be adjusted when the gain is modified. the procedure is to take Bias frames until the image statistics show no values truncated to zero, and the minimal value is not too much above zero. It look like the camera do not use stable enough amplifier so this can be set only once. I not give too much value to the Ascom egain property because I read very bad report about it with some camera. It look like the implementation is very basic and just reproduce the generic manufacturer gain graph. It is also never clear what adu it refer, for example is the unity gain 1.0 or 0.25 with a 14bits camera? apparently the response depend on the manufacturer. But you can read the reported value in the FITS header. |
|
|
A higher gain reduces the camera read noise slightly, but it also reduces the dynamic range significantly. I calculated the effects some time ago and my conclusion was that it only made sense for narrowband imaging with very short exposures — the kind of exposure durations used when imaging unguided. That is only practical if you have a small sensor, but not for an IMX571 camera with 6216×4152 pixels and a long download time. So I assume that less than 1% of users are using a high gain effectively. Most users see that a higher gain makes the image brighter, but they have no idea about the effect on SNR and dynamic range. My problem is that 99% of users now have fixed gain and offset settings. As soon as they have to enter these settings each time, they must do it consistently. Otherwise, you will quickly end up with images, darks, flats, and flat darks taken with different gain or offset settings. This has a major impact on calibration and stacking. If the offset or gain is slightly different, then the darks and flats will overcorrect or undercorrect, and the stacking result will be much poorer. So for me, this new setup is a "Pandora's box." The new setup will allow a very small group to achieve minor or no improvements in noise performance. But for most users, it would require a high level of discipline to use the same settings each time for images, darks, flats, and flat darks. Otherwise, the stacked result will be poor. My stacking program will give a warning if the gain of the images is differently ==== So having the gain and offset settings in CCDCiel is good, but I would prefer to have them in one central location within CCDCiel, such as Edit > Preferences > Camera. If people want to switch camera gain, they could do so by switching profiles. ==== I assume the egain is in general reported correctly. |
|
|
I totally agree with your points, maybe I overreacted with beginner that wanted to manage gain/offset everywhere. When this was discussed in the Ascom group I disagree with this new settings, my idea was that manufacturer must add configurable readout mode for that, but this was considered too complicate to implement. It is the good occasion to fix that now. I like the idea of a single point in the Camera preferences to set the gain and offset once for all the operations. So removing the other options in autofocus and slewing preferences, in preview, capture and sequence step. For the few people that think they need to change the gain during a sequence I can add script commands to modify this central gain/offset values. For the internal guider and finder camera I think it is good to keep this setting where it is in their respective tab, this is already a single point. Beware that today version reset the gain to zero if the program is closed without connecting the camera, this is fixed in current code. |
|
|
I forget about egain. I not understand why you want a display of this value in the interface. This is only one of the criteria to select a gain value, for example photometrist may prefer gain=0 for the maximum dynamic range. Many people use the unity gain because it is near the trigger for the HCG, but the manufacturer also give the exact gain value for this trigger. |
|
|
I implement the single gain/offset setting in Preference/Camera. This is available for testing in version 0.9.96-4138 : https://vega.ap-i.net/pub/ccdciel/daily_build/ The change in the version number is to show a warning about this change when a previous version profile is loaded. The following new script command are available: Camera_GetGain, Camera_GetOffset, Camera_SetGain and Camera_SetOffset. This is a relatively big change affecting many files so this need to be carefully tested. |
|
|
This morning version 0.9.96-4142 display the current gain along with egain in the Capture tab. I think it is useful to have a reminder here. |
|
|
Works all correct here. By placing the settings in preferences it will guarantee consistent settings required for stacking. The reporting egain, gain offset in the tab Capture will be educational and improve awareness of users about these settings. Excellent! |
|
|
It also works correctly with the setup of Gerard. |
|
|
Good, I add the fullwheel capacity information to the gain message, this is also good for the education to have an immediate information about the disadvantage of using a high gain. The same message is now also displayed in the Preview because this is probably the place we test this exposure parameters. The values must be updated when the egain reported by the driver change. Tell me how it work with a real camera, I can only test with simulators this week. This change is available in 0.9.96-4143 : https://vega.ap-i.net/pub/ccdciel/daily_build/ I will make a message on the discussion group, I hope there is not too much deception among people that like to change the gain all the night. |
|
|
I have tested the nightly build version from this morning. Unfortunately it seems that the gain and offset setting have disappeared from preferences. I tested the reporting. See attached. Unfortunately it seems that fullwell capacity is not correctly implemented in the drivers. The ASCOM/Alpaca definition is also akward: >>“The maximum number of photoelectrons that can be held by a single pixel in the camera’s current modes.” In principle the fwc is fixed. That is just the fwc from the documentation. Since they describe “current modes”, I assume they want the “maximum measurable e-.” I will first post something at the ASCOM developers forum to get the definition corrected. Then I can ask the suppliers to implement it correctly. Untitled.png (16,722 bytes) |
|
|
Posted at the ASCOM developers forum: https://ascomtalk.groups.io/g/Developer/topic/definition_of/119511710 |
|
|
Hello Han, The gain/offset setting is still there but it is hidden if a camera that not allow to modify the gain is connected. I not want to show it "disabled" because the values have no meaning,, but I will add a label to indicate the gain cannot be modified. The FW values make sense if the eGain use the scaled pseudo-ADU with a maximum of 65535. if I remember the ASI1600 is 12bit so the pseudo-ADU are multiplied by 16, this make the real FW of 20000 ADU to be 320000 pseudo-ADU. |
|
|
But I also did not see it for the ASI1600. In the previous CCDCiel version, I could modify it from CCDCiel and could confirm by the pixel values it worked. Same for my Touptek. Strange. Yes ASI1600 is 12 bit. Output is 0 to 65535 by a multiplier of 16. fwc, fullwellcapacity unit is e-. So this has to be clarified. I think you where correct saying that the fwc values are often unreliable. |
|
|
I commit the change to show a label when the gain cannot be modified. But to have information why this is not detected it is necessary to check "verbose device log" in the first preference page before to connect the camera. This start with message 'Check camera gain' then log the values or eventual errors. |
|
|
In my simulation all is reported and accessible. See screenshot. So the camera drivers are to blame. Untitled-2.png (4,402 bytes) |
|
|
Is it possible the driver accept the method Gain but not GainMax, GainMin ? The connection with "verbose device log" can show it. But this not change in recent version. |
|
|
Or is it possible this driver do not accept numeric gain but a list of values, like ISO list for a DSLR ? In this case it is possible to modify the value in the preference but it is not reported in the information message, see screenshot. I will fix that today. gain-list.png (26,319 bytes) |
|
|
Later in the day I will debug the code with my Touptek camera. "verbose device log". Not clear to me. In the ASCOM log? |
|
|
The option is in the first page of the preferences, see screenshot. preferences.png (28,743 bytes) |
|
|
It gives a gains list exception. See attached |
|
|
This look all perfectly normal. It is expected the gains list give an exception when the gain range is in use. I can change the function to not do it in this case but this will not change anything. The important is this message: Camera gain:True iso:False This is what trigger the visibility off the gain in the preferences. I also try with the simulator to set GainMax=10000 and this value do not make any problem. Your two camera give similar response, except the range that is different. Is the gain setting visible for the PlayerOne in the Internalguider ? If yes, can you make a test profile with the PlayerOne as the main camera and check the gain options work correctly. |
|
|
Did not have much time today but checked CCDCiel in the debugger. Player one camera as guider shows gain and offset as guider. Player one camera as main camera shows gain and offset,electrons/adu and Fwe-. Did a connect all equipment Touptek camera gain, gainmin,gainmax are read. But in function T_ascomcamera.CheckOffset, the FInterfaceVersion is 2 and offset, ofssetmin,offsetmax are not read. Full welcapacity =0 So it reports: Gain: 100, eGain: 1.000, If only the camera is connected, nothing is reported. Resume: 1) The main problem is that nothing is reported if only the camera is connected. I checked my Touptek camera and the ASI1600 of Gerard by only connecting the camera. I should have done a connect all. 2) Touptek reports interface 2. Then offset is not read and reported. Is it wise to check for interface version? I assume Touptek forgot the increase it. cs, Han |
|
|
Thank you for the testing. The problem when connecting the camera individually is because of another change I do in previous version and the different way this is initialized between Ascom and Indi. This is fixed by https://github.com/pchev/ccdciel/commit/21aea5d1f7f830ee1d99e0a2eeef51dcc765b59e I not check the offset if the version is not at least 3 to prevent unneeded exception. I think this is something to report to Touptek first, the Ascom documentation is clear that Offset is new with version 3. |
|
|
This morning I removed the check on FInterfaceVersion>=3 for the offset and it generates an exception. So offset is not supported by the Touptek camera driver. I looked at ASCOM Standards documentation, but I can not find any documention about which interfaceversion required for each method. I only wondered why in CCDCiel the interfaceversion is checked for offset but not for gain or Isolist? Is it possible to allow setting the gain for the case that only the camera is connected? So without connect all? |
|
|
Thanks. I compiled your last code. Worked as expected. This issue can be closed |
|
|
My description was not clear, but the change I mention in my previous message fix the case when only the camera is connected. I not check the version for the gain because it was added with version 2 in 2011, this is old enough to no more have version 1 drivers around. The interface version for a method is indicated in the documentation if was not in the initial specification. For example: https://ascom-standards.org/newdocs/camera.html#Camera.Offset You also have a file installed with the platform that give the full history, look for ASCOMInterfaceRevisions.pdf in C:\Program Files (x86)\ASCOM\Developer\Developer Documentation |
|
|
I want to continue a bit on this subject because I am not totally convinced it is a good change to remove the gain/offset from the Preview settings. I really like the single point setting for all the other use and not want to touch that. But I think an independent setting only for the Preview can be good. Because now if one think it need to increase the gain to see something, it need to change the global gain, and if it forget to set it back it will take the capture with the wrong gain. You proved in the other report that changing the preview gain for 16bit camera is not necessary. But there is many camera with lesser ADC that can benefit of a higher preview gain. The lesser the ADC bit depth is, the more critical it is. This is not only for old camera, for example the recent and very good IMX585 is 12bit. What I propose is to add the gain/offset back to the preview tool, this will be used only for preview. I think it is best the values are not saved independently, but they reset to the default gain/offset every time the program is started. Do you have any remarks about that? |
|
|
Yes why not. People can experiment with it. Especially with very short exposures. But I doubt it will help if stretching is working well. Any gain change will now be corrected automatically and preview will not change except maybe the SNR value due to the small change in read noise. I would suggest to add the option for the gain only. In modern cameras, the offset is stable and not dependent on the gain. I will have fu_visu.pas ready this afternoon. |
|
|
I also commit the change that add the preview gain setting. It is optional with a checkbox to activate it. Every time is is unchecked it reset to the default. When unchecked you can see it as the previous information label. I let the offset setting too, I not want this to be a limitation for old camera. https://github.com/pchev/ccdciel/commit/f357d0ded87b3bca902c6843824f165ba6b5f0b2 |
|
|
This will allow everybody to experiment with gain. As soon there is clear sky, it will be interesting to see if the gain has a influence on the preview. I expect not. I have to wait a few days before the weather allows field testing. But let other users test it by announcing the change. |
- Anonymous
