14 Bit Image, 16 Bit Processing

[pfile]

actually, i had forgotten what they are doing. they are calling DCRAW with -D, but then they are scaling the data somehow. perhaps it's only a right shift, the authors never elucidated what exactly they are doing. if its only a right shift, then its OK.

rob

edit: i did go back into the thread and the thing that got me started on this is that i noticed that saturated stars did not have the value 16383, which is what i expected from a 14-bit sensor. but if they are only shifting left 2 bits, i would expect to find 2'b1111_1111_1111_1100, or 65532. instead i was seeing values in the high 50k, which did not make sense to me. i started looking at DCRAW options and wondered if they were calling with -d, but someone set me straight - they are using -D but subsequently doing some kind of 14b->16b scaling in the background. still if it were as simple as a shift left, the 50k values do not make sense.

[Nocturnal]

I think the SGP guys are good at what they do. More importantly if they did this wrong no one with a DSLR would use their software

Back to the original question, the capture software should not mangle the input files. 16b vs. 14b vs. 12b matters not as long as no bits are thrown away on either end of the 16b int. In case of doubt you can try the free APT software for a sanity check. It is not so easy to use but it may be helpful in this case. Works great with my ASI1600. It started out at DSLR centric but as ASCOM camera support.

If you can't figure it out, upload a single dark, light, flat and dark flat somewhere. Preferably a single 7z or zip archive for easy downloading. We can see pretty easily if the data is good.

[pfile]

fair enough. my opinion is just that a capture program should never modify the data coming from the camera, even if the operation amounts to a NOP. they ended up in this situation where their fits files are incompatible with CR2 files unless some further (unknown) transformation is made to the CR2 files.

rob

[Juan Conejero]

they ended up in this situation where their fits files are incompatible with CR2 files unless some further (unknown) transformation is made to the CR2 files.

The real problem here is, besides a wrong (IMO) manipulation of the raw data, the FITS format. With XISF, you *always* know how to correctly interpret *any* image, irrespective of the transformations or rescaling operations applied, and independently on the pixel format used. With FITS, anything is feasible and everything can be expected.

[Nocturnal]

Agreed. I have been led astray by the right shift that the ASI driver does. In my case it's not APT that's doing it though. I suppose DSLRs are a bit of a special case. For them I'd stay with the native raw format if I could.

At the same time sometimes you are stuck with the software you have and then it is helpful to know what is affecting your images and what is not. Assuming the chances are low that the software will change I would be glad to know what it is doing is harmless. If it is not harmless and won't change then that's a clear sign it is not the right software