IMX378-190 General Comments

[StarGeezerPhil]

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

dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off

Disable the Activity LED

dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

Disable ethernet port LEDs

dtparam=eth_led0=4
dtparam=eth_led1=4

(Sadly, it seems impossible to disable the LED on the Pi POE-Hat - if anyone knows how, please let me know)

[aaronwmorris]

Thanks for this!

I will try get some of my wiki pages updated with this info.

• Resolution - I will think about what it would take to implement resizing the images just for ffmpeg.
• Gain - I assume the gain options are the same for the IMX477, but that could be wrong. If it is wrong, I will have to create a different profile for the IMX378.
• Disable LEDs - I have a wiki page for this, but I think it would be helpful to add this option as an alternative. https://github.com/aaronwmorris/indi-allsky/wiki/Disable-LEDs
  • I did not know it was possible to disable the NIC leds, that is really cool

[StarGeezerPhil]

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).

[aaronwmorris]

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.

[StarGeezerPhil]

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.

[aaronwmorris]

I am going to play with adding an option to scale the vertical resolution

[StarGeezerPhil]

Ping me if you get a working test - be happy (and keen) to test it out 👍

[aaronwmorris]

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.

[aaronwmorris]

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.

https://en.wikipedia.org/wiki/Advanced_Video_Coding

[StarGeezerPhil]

That IS exciting news! Going to need a bigger SD card 🤣

Look forward to the updates Aaron 🥳👍

[aaronwmorris]

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.

[aaronwmorris]

Hah... my Raspi4 4GB ran out of memory trying to build a full resolution timelapse video

[290258.454992] Out of memory: Killed process 148816 (ffmpeg) total-vm:3640732kB, anon-rss:2697684kB, file-rss:1888kB, shmem-rss:0kB, UID:1000 pgtables:5940kB oom_score_adj:0

[StarGeezerPhil]

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? (I know there's an issue logged somewhere with the details but it's difficult to find).

Also, just general UX suggestion (though, I guess once we're each setup and optimised we rarely need to go back into config):

• maybe separate the options into tabs like "Environment", "Imaging", "Processing", "Output", "FTP/Upload" or something similar. The config is GREAT - just that there are so many options now I'm often scrolling up/down the list and there's few visual queues to stop me in the right place. Just some headings with something visual (e.g. bootstrap icon) would help the end-user quickly navigate to the right settings.

No complaint - just an idea/feedback 👍

[aaronwmorris]

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.

Check the system log with sudo dmesg and check for out of memory messages. That is one of the most common reasons for ffmpeg to fail other than inputting images of different sizes.

Images - getting neither startrail or keogram generated from the IMX378 images from last night's first test...

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.

maybe separate the options into tabs like "Environment", "Imaging", "Processing", "Output", "FTP/Upload" or something similar

The size of the config page has grown considerably and I will be splitting it into multiple tabs soon.

[StarGeezerPhil]

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.

[aaronwmorris]

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.