I have seen the image circle being off center, but that is the worst case I have ever seen. The image sensor itself must be not centered to the body of the camera, it may be worth disassembling to fix.

I will get around to this eventually. The upload status (and S3 upload and SyncAPI) are tracked in the database.

The labels are part of the image itself. The only way to get rid of them is just disabling image labels entirely.

The FOV is a function of the lens and the image sensor. Getting a larger sensor will result in seeing more of the image circle, which expands the view a bit. The following lens is well known for a large image circle. It has gone by a few names, but can be hard to find:
www.dewcontrol.com/155mm_All_Sky_Camera_...099125_19122279.aspx

The Allsky Camera Facebook group has a lot of posts...
www.facebook.com/groups/172438633343696/

yeah, off-center is being nice to it. I took a look at the camera, but I don't have a tool narrow enough to reach down the hole to get to the screw heads... perhaps if I drop it in the other direction... I joke.. maybe. I did spin the lens to make sure it wasn't the lens elements, it isn't. The offset stays with the sensor while turning the entire lens.

Thanks for the video upload work over on github. Each one of the stills and videos shows things in a unique way.

I know the labels are written into the image, and I do like to see that information as well. I was just wondering if there might be a way to store the data in the image metadata layer, like exif, or fits header, such that a viewer could still display the data overlayed on the image if desired, but for stacking there would be nothing but sky. It does sound like a lot of work though.

I did look around a lot for another lens, as the FOV of this one leaves a bit to be desired, but it is the best I can get for now. Thanks to for the link, though I cannot find that one anywhere yet.

Jim

I have had sufficient people ask for the EXIF data so that is what I am working on now. To date, I have been using the OpenCV imread/imwrite commands to read/write images. Unfortunately, OpenCV does not support writing EXIF data and the developers do not really seem to be interested in implementing it.

Therefore, I am replacing the image IO with the Python Pillow module. The good news is Pillow appears to be significantly faster in these operations. Saving 20ms does not sound like much until you have to read 3000 images to generate a keogram. That is a full 1 minute speed improvement on a process that takes 10-15 minutes.

Using a Pi 4 8gb - installed indi-allsky.
I have a QHY678C i'm trying to connect to it but can't.
I did the fxload for usb 3.0 support but do not see an .img file for the qhy5iii678
Tried to do it with the 486 image file and didn't seem to work.

I'm going to try to reinstall everything.

Can you tell me if the 678 is supported?
.

There is a QHY5III678.img that was just added one month ago, probably for the indi 2.0.1 release. It will not be in the astroberry repo which is still at indi 1.9.7.

You can follow these instructions to remove the astroberry repo: github.com/aaronwmorris/indi-allsky/wiki...tall-indi-repository

Then you can run ./misc/build_indi.sh to compile indi from source. I believe it will take 30-40 minutes on a Pi4.

Any update/progress for the planetarium overlay? I think you’ve already tried with VirtualSky correct?

Disregard - all working - Driver problem.

I did make an attempt with VirtualSky. I could not get the VirtualSky [HTML5] canvas to overlay on top of the indi-allsky image canvas. TJ's allsky overlays the VirtualSky canvas on top of a plain <img> element, which is the primary difference.

I tried, but it is above my skill level with HTML.

Creating exif metadata is proving to be considerably more difficult than I thought it would be. Reading exif data is fairly well documented, but creating exif data is much less obvious. There are a lot of projects that appear to be unmaintained as well.

I just merged a change that adds EXIF tags for the created JPEG files. All (well, most) of the image reading and writing has been replaced with Pillow.

I switched over to using Pillow today, seems to work well. I also switch the lens out with a different one, and notched the sensor board so that I could re-adjust the center of the sensor. That was its own story, and the camera is now sensitive to the tightness of the screws holding the board down. I wanted to use the lens right away, so I found this print very helpful: www.thingiverse.com/thing:4810077 - it allows the M12x0.5 threaded CCTV lenses to be mounted into the T2 threads of the camera. Surprisingly, the printed threads are very good. The lens focus is a bit too tight yet, but once set, it should not move. I am still messing with the focus. It almost feels like putting the dome back on changes the focus, which would be unfortunate. This is the lens in case anyone is interested: www.amazon.com/gp/product/B07DJZJD8V/ref...03_s00?ie=UTF8&psc=1

Here is a sample picture in full sun. The FOV is much better.

I was having too many problems with the 290MC, and will chalk it up to being an early model. I purchased a 662MC, and so far, this is a keeper. It is able to pull out the Milky Way in our terrible Bortle 5/6 type skies with the right settings and a good focus. It would probably make an excellent guide camera.

Jim