Wrong input format from Panasonic (Lumix) Cameras

[Cepadues]

Hi everyone, I've recently discovered that my camera, a Lumix GX80, had an LumixCameraAscomDriver.
The only way to connect and control Lumix cameras is over Wi-Fi, which the driver implements.

The driver allows to set the speed, iso and format of the camera transfers the image (Raw or JPG) on the PC and exposes the image array in RGB to the calling program. This will create a 16bit image regardless of what the transfer format was. [...]
It relies on LibRaw to handle the Raw format, or the native VB.NET imaging for JPG Images are then translated into Tiff and then passed to the image array.

The camera connects correctly, I'm able to take snapshots as you would expect from a DSLR Camera, but Sharpcap seems to be translating the pixel values incorrectly :

I have a feeling that the ASCOM driver is passing RGB arrays to Sharpcap which expects something different (the ImageArray function of the driver).
I've checked the input files (both RW2 and tif) and tried to use it with NINA but it seems like everything is working correctly.

I've attached both ASCOM and Sharpcap's log files, I still have the input files (both .RW2 and .fit), however I can't attach them due to the size limits.
I'd like to know if there's anything I can do on sharpcap's side to make the 2 things work together or if I'd have to modify the ASCOM driver. In the latter case, what format does sharpcap expect to receive ?
Any help is welcome !
Best regards

[admin]

Hi,

I can see the shape of the image their in the garbled picture, so I don't think it's an issue with the format (that would probably make everything 3 times too tall or 3 times too short if it was getting RGB but expecting RAW or the other way around).

What I suspect is that the value that the ASCOM driver is returning to SharpCap from the MaxADU property is wrong. SharpCap expects this to be the maximum pixel value that will be in the pixel data. By the look of the driver it is returning 4096 from the MaxADU, but perhaps it is scaling the image pixel values up to 65536 maximum? If the two are consistent then the image should come out correctly.

So, hopefully just a tweak to the ASCOM driver - by returning 65536 not 4096, you will stop SharpCap from multiplying all the pixel values by 16 (thinking it is doing the right thing) and get a correct image.

cheers, and good luck!

Robin

[Cepadues]

Hi,

What I suspect is that the value that the ASCOM driver is returning to SharpCap from the MaxADU property is wrong. SharpCap expects this to be the maximum pixel value that will be in the pixel data. By the look of the driver it is returning 4096 from the MaxADU, but perhaps it is scaling the image pixel values up to 65536 maximum? If the two are consistent then the image should come out correctly.

You were right, after changing that value I was able to get ungarbled pictures.

Thank you very much !

Best regards.

[admin]

Hi,

glad to hear that fix worked. I suspect it means that other programs like NINA do not take any notice of the MaxADU property, which is fine except that they may display images as being dark if (for instance) a driver only produced values up to 4096.

cheers,

Robin

[Cho_MeowZz]

Hey, I too have this same issue with my Rebel T7. Can I know what to tweak with it? (New to ASCOM Driver link-Sharpcap)

[admin]

Hi,

the rather trippy image shown in the first post was caused by the ASCOM driver reporting a MaxADU value that is lower than the actual maximum pixel value in the image. If the ASCOM driver has any configuration for the maximum ADU or maximum pixel value, try increasing that until the effect goes away (try doubling it, then quadrupling, etc, until you reach 65535).

cheers,

Robin