How wide is my sensor? ASCOM driver vs Raw via Pixinsight

Linwood

Well-known member
I am using a Sony A7Riv camera with (somewhat beta) ASCOM drivers.

If I load a raw ARW file into Pixinsight, it thinks the dimensions (before debayer) are 9568 x 6376.

If I capture a file as FIT in APT using the driver the size is 9600 x 6376 (I also did some debug runs and the size is coming from the driver not APT).

I found this after I spent about a day building Bias and Dark libraries using raw (because it was easier and faster) and then went to integrate with flats taken with APT and ... geometry mismatch.

Obviously I can decide to use one or the other exclusively but... Which one is right?

(This may seem like a simple question of looking up the sensor size, but ever spec I can find only lists it after debayer at 9504 x 6336).

Linwood

PS. I've asked the driver developer also, but that Pixinsight is finding a smaller number I'm more suspicious the problem is there. Note also the height is the same in both.
 
when you say "sony driver" what do you mean? if you are talking about Sony's software, then i would assume they have developed their own software rather than relying on libRaw, which has reverse-engineered all the DSLR formats.

even the manufacturer's software doesn't necessarily give you the entire array with the native software. most of these sensors have overscan areas which are not exposed to light and are used by the camera firmware to do its own calibration. libRaw may or may not be including these areas. furthermore the libRaw developers have changed their minds at least once about how how much of the sensor on certain canon cameras should be given to the user. this has resulted in the bayer matrix for some canon cameras switching from RGGB to GBRG since they chopped off one row.

so that's the key thing - the size of a DSLR sensor is somewhat open to interpretation by the software and different software packages do different things. short of using pixelmath to crop off rows of data, it's best to stick with one file format produced by one piece of software. even two software packages using the same raw decoder might do different things with the data, which is apparently what's going on here. note that this problem is not limited only to file dimensions - SGP rescales 14-bit DSLR data to fill the 16-bit integer space which makes CR2 files incompatible with SGP DSLR fits files when opened by PI.

rob
 
No, another astrophotographer developed a sony DLL and ASCOM driver connection for the Sony's. This link introduces but the current code is available at links at the bottom on github.

https://retro.kiwi/ascom-driver-for-sony-cameras/

I guess I was surprised that both used the same library and got different results. From your description it would seem to imply a pixinsight person decided to truncate a bit for some reason (since it's smaller)?

It's kind of a shame -- using the ASCOM drivers is a bit of a pain for something like bias. I did about 600 images at four ISO's pretty quickly in raw, then converted in pixinsight in batch and integrated. Doing it with the driver is about 6-8 seconds each due to USB download times. I guess the good news it's a (mostly) one time thing; flat and dark probably going to be with a capture program anyway (dark to be > 30 sec and flat just because everything is already there when imaging).
 
PS. I already checked that neither is scaling; so they do match in terms of raw pixel values. Never occurred to me to check geometry.
 
I guess I was surprised that both used the same library and got different results. From your description it would seem to imply a pixinsight person decided to truncate a bit for some reason (since it's smaller)?

not necessarily - it's just that libRaw has a lot of knobs and "pure raw" in PI might not be the same as how APT configures the ascom driver, or the same as how the ascom driver calls libRaw. i'm sure if you keep pulling the thread you can figure out what is different. i think PI exposes all the libRaw controls in the RAW configuration dialog box, and if you are lucky you can match the configurations.

of course all things are possible with PixelMath - if you can figure out what rows/columns are missing between the two types of images you can fix up the larger images to delete the proper data.

the scaling thing was just an example - essentially you are mixing capture programs here and the SGP example was meant to illustrate how incompatible data could arise even from the same program, just due to the file format changing. generally speaking changing capture programs between calibration and light frames is not good... because of exactly what you are seeing here.

rob
 
OK, I guess I'm stuck using APT for all exposures, or passing raw ARW files in all the time. The problem with the latter is that it doesn't capture any of the light frame details - scope ra/dec, type (light/dark/bias/etc). I can back into most of these I guess. But APT appears to insist on receiving the file even if I save the Sony raw data (i.e. I get two copies).

Sadly the Sony driver is a bit flakey (I've just had APT abort twice reshooting my bias frames). But I really NEED it for longer than 30 second exposures since that's how long the intervalometer does.
 
of course all things are possible with PixelMath - if you can figure out what rows/columns are missing between the two types of images you can fix up the larger images to delete the proper data.

Hmmm... A difference should highlight that if I can figure out how. That's a good thought. Pixelmath not dynamic crop?
 
I found it; there is a "no image crop" under the raw format settings that was not selected. It says:

crop.jpg


When checked, I do get the same size image as the ASCOM driver. So I can make them match. I assume cropping off the edge will handle any issues, though I do worry a bit that if this is used internally by the camera in some way this might throw off some of the math.
 
i think it should be ok - calibration is done on a pixel-by-pixel basis so that much is OK, "real" pixels won't be affected by the uncropped 'extra' pixels.

possibly the last real row/column would be negatively affected during debayering but that's probably not a big deal - if you are dithering you probably have to crop the edges of the integrated frame off anyway.

there should be a format hint for this, i will have to dig thru the code. hopefully WBPP will keep the "no image crop" setting (i'm sure WBPP calls the raw decoder with the format hint "pure-raw" which is what you get when you click the pure raw button in the RAW configuration, and that could possibly override what is set in the preferences panel.) maybe there is a place to pass format hints to WBPP... i use a mono camera which is pretty straightforward and never had to look into this.

rob
 
Yeah.... the setting does not work reliably. I set it and indeed opening an ARW (raw) file works fine, not cropped. Then I did a batch conversion of the raw files to xisf (because otherwise I run out of memory integrating) and it cropped during the conversion. So the raw options are not honored at least in the conversion script.

I also got info from the developer of a way to force his routine TO crop, which I guess is an option, but leaves me just a tiny bit worried to be sure it's cropping the same way (not just to the same size), and no real good way to tell.

Maybe I'm too new to Pixinsight to say it, but to me that's a bug -- it ought to be the same throughout.

PS. I'm not sure what WBPP is above, if it's some preprocessor (PP?) I'm not doing that, I'm trying to learn all the steps and apply each individually to build up a library. Except now I can't seem to get a library I can run against my (uncropped) lights.
 
the batch conversion script *should* honor the settings in the RAW module. however it does accept format hints and by default the format hints "raw cfa" seem to be applied. i think the presence of any input format hints causes an override of the RAW module settings. this is a good thing since you can essentially configure the module on a per process/script basis rather than having to go in and change the RAW module settings and then run. without input hints the processes don't stand alone from a configuration standpoint.

according to the source code, the hint "no-auto-crop" should do what you want. so if you add that input format hint to the batch conversion script it should work right for you. or, probably deleting the input hints would then make it take the config in the RAW module as you've left it.

WBPP is the weighted batch preprocessing script and yes it is a script to do all the grunt work involved in matching darks with lights and filters with flats, etc. but it is a very good idea to do what you are doin gto understand how it all works.

rob
 
oh by the way, to see all the format hints, click on the RAW entry in the format explorer and then double-click the word "implementation"

rob
 
Thank you. I was working through forcing a crop instead (good because it taught me about image containers and mass processing with them). But now I have options.

And now I know how to find the hints also, which I had not yet found (but wasn't sure I needed).

Learning is a process difficult to automate. :geek:
 
Just for closure of anyone following...

With the no-crop set in the format defaults for raw, leaving the input format hints at the default "raw cfa" results in a crop (i.e. raw format setting ignored).

Blanking the hints results in no crop (I did not try to see if the CFA/RAW still took affect).

Adding "no-auto-crop" to the hints results in no crop.

It's necessary to convert raw to xifs for memory reasons if you have a lot of images, so I'm converting raw first step in processing, then the cropping won't matter after, so whether the raw defaults work right in the other places you have input hints won't matter (for me).
 
With the no-crop set in the format defaults for raw, leaving the input format hints at the default "raw cfa" results in a crop (i.e. raw format setting ignored).

Blanking the hints results in no crop (I did not try to see if the CFA/RAW still took affect).

Adding "no-auto-crop" to the hints results in no crop.
Input hints allways overrule the settings in the Format Explorer; this is intended behavior and reasonable.

Cropping as the default when using the 'raw cfa' hint is just fine; some sensors have an optically black or overscan region. Normally you want this region to be cropped, unless you want to perform an Overscan calibration.

Bernd
 
Input hints allways overrule the settings in the Format Explorer; this is intended behavior and reasonable.

Cropping as the default when using the 'raw cfa' hint is just fine; some sensors have an optically black or overscan region. Normally you want this region to be cropped, unless you want to perform an Overscan calibration.

Bernd

Well, again, newbie here, but in the FWIW department input hints overriding the default would make more sense if the input hints themselves were not defaulting into the screen. Having manual (i.e. entered) values override defaults I get; having one default overriding another seem... confusing.

My underlying problem is one of my own making though -- mixing raw images with ASCOM driver captured images. If I were doing one, or the other, this would not even be an issue. Just that I can do 600 bias frames in a few minutes in raw with the camera, but I can't even get APT to take more than 26 images before it crashes. Not awful for lights where I might get only 2 or 3 times that many and need to batch. A pain for large numbers. The woes of a niche camera with minimal support. :(
 
Input hints allways overrule the settings in the Format Explorer; this is intended behavior and reasonable.

Cropping as the default when using the 'raw cfa' hint is just fine; some sensors have an optically black or overscan region. Normally you want this region to be cropped, unless you want to perform an Overscan calibration.

Bernd

true, but we were trying to solve this problem:

mixing raw images with ASCOM driver captured images. If I were doing one, or the other, this would not even be an issue. Just that I can do 600 bias frames in a few minutes in raw with the camera, but I can't even get APT to take more than 26 images before it crashes.

rob
 
true, but we were trying to solve this problem:
Yes, I know. I have done that for my Canon EOS 600D (T3i) once. This was possible because in SGP you can set that the same frame is saved both in CR2 AND in FITS format.

Since I don't have a Sony A7Riv, Linwood would have to provide such a pair of frames. Maybe that APT is capable of producing that?

Bernd
 
Yes, I know. I have done that for my Canon EOS 600D (T3i) once. This was possible because in SGP you can set that the same frame is saved both in CR2 AND in FITS format.
You mean an ARW fresh from the camera and the same from from APT?

Sure. Here's a zip file with each in it, one FIT and one ARW. I think the data in the FIT is a bit for bit copy of the image data itself in the raw; love to know if you find otherwise.

https://drive.google.com/file/d/11SP4WvYEEXOTHrwnZxDPh0hlvZEES5j3/view?usp=sharing

Zip is about 69mb, the files are about 120mb.

I've been saving the images as I capture to the camera's card anyway, but trying to use the FIT image as it contains (for lights) the telescope pointing info, as well as the file names indicating dark, bias, light, etc.
 
Back
Top