I did find a seemingly great deal on a NexImage 5, so I did get it.
Here is the USB ID:
Bus 003 Device 055: ID 199e:8207 The Imaging Source Europe GmbH
Based on the driver package prior to seeing it, I was able to track back it, and most other Celestron cameras back to The Imaging Source. Which lead me to here:
github.com/TheImagingSource/tiscamera/wi...USB-2.0-CMOS-Cameras
I followed that procedure, with the commands in bold, and the serial number replaced with <SERIAL>
sudo ./firmware-update -l
Found 1 device(s).
Name - ID - Serialnumber
NexImage 5 - 199e:8207 - <SERIAL>
sudo ./firmware-update -id <SERIAL>
Device manufacturer: Celestron
Product name: NexImage 5
Serial number: <SERIAL>
VendorID:ProductID: 199e:8207
Firmware version: 129
UVC mode is: off
Camera EEPROM size: 32768
sudo ./firmware-update -ud <SERIAL> -f ../../../data/firmware/usb2/dfk72uc02_3012.euvc
!!! Attention !!!
This action could break your camera.
Do you really want to proceed? [y/N] y
Firmware Size: 19968 EEPROM Size: 32768
100 %
Upload successful!
Please reconnect your camera.
sudo ./firmware-update -id <SERIAL>
Device manufacturer: Celestron
Product name: NexImage 5
Serial number: <SERIAL>
VendorID:ProductID: 199e:8207
Firmware version: 196
UVC mode is: on
Camera EEPROM size: 32768
Following that, the camera worked, and at low exposure time, gave me a great picture of some garden flowers, along with insect, via a Celestron First Scope Telescope (using v4l2 and guvview. A 76mm/300mm FL telescope. I'd see about a picture of stars, but there's the issue of these things called clouds that show up as an extra on seemingly any astronomy related purchase. This one came with a very large free package of wind as well!
Unforuntely, INDI doesn't seem to be as cooperative as guvcview.
This appears to be because of the formats supported:
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'GREY'
Name : 8-bit Greyscale
Index : 1
Type : Video Capture
Pixel Format: 'GRBG'
Name : 8-bit Bayer GRGR/BGBG
Which looks like a 2 line pattern, if that's to be believed. Based on looking at guvcview's colorspaces.c it looks like that's how it's handling it.
If trying to stream, you get ... basically static.
For now, greyscale seems to work. I've been piddling around with a new conversion:
void bayer_grbg_to_rgb24(unsigned char *dst, unsigned char *src, long int WIDTH, long int HEIGHT)
{
//Format is
// GRGRGRGRGR
// BGBGBGBGBG
// GRGRGRGRGR
// BGBGBGBGBG
long int row;
long int col;
long int src_pixel;
long int src_pixel_row2;
for (row = 0; row < HEIGHT; row++) {
for (col = 0; col < WIDTH; col++) {
i=(row*WIDTH+col)*3; //Output is in 3 bytes RGB, so convert a single pixel each time.
src_pixel=(row*WIDTH+col)*2; //Bayer pattern has 2 bytes in first row: GR
src_pixel_row2=((row+1)*WIDTH+col)*2; //Bayer pattern has 2 bytes in 2nd row:BG
dst[i]/*RED*/=src[src_pixel+1];
dst[i+1]/*GREEN*/=(src[src_pixel]+src[src_pixel_row2+1])/2;
dst[i+2]/*BLUE*/=src[src_pixel_row2+1];
}
}
}
I've added in the case to adjust the size of the rgb24_buffer based on pixel format: case V4L2_PIX_FMT_SGRBG8: in v4l_builtin_decoder.cpp, allocBuffers() but I'm a bit at a loss on it. Sometimes, it runs for a few minutes, and sometimes it fails immediately. It's probably something stupid that someone will see immediately above.
Unless the *src has some size issue.