IMX378-190 General Comments #568
Replies: 16 comments 29 replies
-
Thanks for this! I will try get some of my wiki pages updated with this info.
|
Beta Was this translation helpful? Give feedback.
-
No trouble - anything else I find I'll post. Not managed to find anything to disable the big red LED on the PoE HAT sadly. Yeah, if there's anything you can do for ffmpeg it'd be great mate - have a lot of captures that I simply can't timelapse at the moment. In the JQ Allsky he has a ffmpeg commandline option, which would allow me to do some testing for you, but suspect it'd be something like I put in the other bug thread, e.g. -vf scale=-1:2304 (assuming the scaling option can work with either X or Y - it might be limited to just X resolution). |
Beta Was this translation helpful? Give feedback.
-
You could dab a bit of caulk for a non-permanent fix. I tested some other SoCs and they had some LEDs that could not be turned off. I just broke the LEDs off with needle nose pliers. FYI, SMT LEDs come off much easier than I thought they would. |
Beta Was this translation helpful? Give feedback.
-
I've just moved it into a solid opaque case - so it's less of an issue now, but would be good to permanently disable it. Waiting on a new dome to fit and looking at some flocking this time around to reduce reflections in the dome. |
Beta Was this translation helpful? Give feedback.
-
I am going to play with adding an option to scale the vertical resolution |
Beta Was this translation helpful? Give feedback.
-
Ping me if you get a working test - be happy (and keen) to test it out 👍 |
Beta Was this translation helpful? Give feedback.
-
I have been testing adding the option and I just happened to test trying to encode the original resolution of the images and ffmpeg allowed it... I wonder if this was just a limitation of ffmpeg in Buster. |
Beta Was this translation helpful? Give feedback.
-
Confirmed. I see in my log ffmpeg used profile level 6.0. Newer versions of ffmpeg support H264 level 6.0+ which supports higher resolutions up to 8192×4320. |
Beta Was this translation helpful? Give feedback.
-
That IS exciting news! Going to need a bigger SD card 🤣 Look forward to the updates Aaron 🥳👍 |
Beta Was this translation helpful? Give feedback.
-
I have merged the new config option #335 to perform the vertical scaling. I had originally intended on adding more options like a standard 1080 (1k) and 2160 (4k) option, but it is not that easy. Whatever scaling option you choose has to result in a horizontal and vertical resolution that is divisible by 2 and this does not always happen. I can always add more options, but each option will likely be camera specific. |
Beta Was this translation helpful? Give feedback.
-
Hah... my Raspi4 4GB ran out of memory trying to build a full resolution timelapse video
|
Beta Was this translation helpful? Give feedback.
-
Hi Aaron, sorry life took over for the last month and the cover for my V2 skycam got lost in the post... finally back on it again 🥳 Hopefully fully waterproof, with some ventilation, IMX378 and flocking beneath the dome this time around, so 🤞 I'm having some trouble with the image and video generation. Video generation - seems to be the bitrate more than anything else that affects it. Was hoping to generate higher quality video at 2304px, 75%, or 1520px, but if I increase bitrate beyond 4000k the video seems to fail. When I reduced to the 4000k bitrate my timelapse is now generating. Images - getting neither startrail or keogram generated from the IMX378 images from last night's first test... ...could you add the troubleshooting cmd line options into the wiki? Also, just general UX suggestion (though, I guess once we're each setup and optimised we rarely need to go back into config):
No complaint - just an idea/feedback 👍 |
Beta Was this translation helpful? Give feedback.
-
Check the system log with
If you changed any of the image scaling options, this can happen. All of the images must be exactly the same dimensions in order for the keogram or startrails to generate.
The size of the config page has grown considerably and I will be splitting it into multiple tabs soon. |
Beta Was this translation helpful? Give feedback.
-
Hi Aaron, what was your conclusion about gain for your sensor. I thought that gain went up to 16 as I commented above, however last night it appeared there was no difference for gain set between 5-16. (Unless I didn't apply the config correctly). I'll continue digging. |
Beta Was this translation helpful? Give feedback.
-
In order to change the gain, you have to fully restart indi-allsky. The reload option is not sufficient. (I probably need to note this somewhere) There is not a lot of information about the IMX378 out there. I cannot even find a datasheet. I found the datasheet for the IMX377 which says gain is up to +27dB in 0.1 increments. But this does not mean anything with libcamera. ZWO allows you to set gain in 0.1 increments... 270 means 27dB. QHY supports the whole numbers so 27 would mean 27. Anything above these would go into digital gain (instead of analog). I may have to hunt through the libcamera source code. |
Beta Was this translation helpful? Give feedback.
-
Hi @aaronwmorris, I've just swapped out the sealant, remounted the camera higher (190° lens - originally capturing a lot of the box/silicone) and I'm trying to collect more darks. (Back to one of our earlier conversations about gain...) The dark script reports gain 16 as the max for the IMX378 - reported as below:
|
Beta Was this translation helpful? Give feedback.
-
First off - huge thank you @aaronwmorris for introducing support for the IMX sensors so quickly, really appreciate it.
Especially - also covering off the defective pixel correction (DPC) (Star-Eater Algorithm) so quickly too! 🔥
I'm testing with the IMX378-190, so just my notes so far for anyone else using this Waveshare module for the Pi...
Enable Camera: Follow the Waveshare instructions, or apply the following steps to get the camera working:
sudo nano /boot/config.txt
Then add the following to the end of the file:
dtoverlay=imx378
Colour balance in INDI-AllSky - I've found this required quite significant changes (not tested with auto-white-balance), but these settings seem to be close to optimal for me: 0.65, 0.55, 1.10 (R:G:B)
Resolution is too high for the timelapse video creation, however I'd rather keep my high resolution individual images than resize them all. Is it possible to add a resize option for just ffmpeg anyone?
Gain; darks script indicates maximum value is 16.
Noise; there is A LOT of noise. Capture darks! However, there is currently no sensor temperature captured in INDI-AllSky, so they won't be temperature calibrated - but even so, it makes a HUGE improvement to the image quality.
Disable LEDs: Not IMX378-specific, but Pi users - I'd recommend disabling the LEDs to avoid introducing unwanted light into your exposures:
sudo nano /boot/config.txt
Then, add the following to the end of the file (for Pi 4, presumably 3 too?) - broken up as github markdown turns comments into titles:
Disable the PWR LED
Disable the Activity LED
Disable ethernet port LEDs
(Sadly, it seems impossible to disable the LED on the Pi POE-Hat - if anyone knows how, please let me know)
Beta Was this translation helpful? Give feedback.
All reactions