#4 Ignore exif rotation in raw files or implement proper rotation of bayer-pattern also

[prof7bit]

When accidentially having exif-rotated raw files in the stack (some cameras can't disable writing this flag) then the debayering produces unwanted results. Yesterday I dropped a bunch of raws from my Olympus camera into ASTAP and got very strange results. Although they wer all plate-solved and aligned properly the colors of the final image were totally off and a fine 2x2-pixel grid was visible.

Upon further investigation I noticed that half of my images were rotated 90 degrees indicated by an exif flag (the camera did this when the telescope slowly rotated). I was able to stack each of these halves individually but the "auto" detection of bayer-pattern worked only on the unrotated ones. The other half of the stack I had to manually choose a different pattern.

At the moment I am investigating whether it is possible with some tools to fix my exif headers in these raw files, but the better solution would be when ASTAP simply completely ignored the image rotation, I have not found any option to do so.

I have attached a zip with 2 raw files that trigger the problem.

[han.k]

Yes that is a problem.

I tested it with the DCraw and Libraw convertor. Luckely the Libraw convertor seems to ignore the rotation. There where some other problems with black borders using Libraw but for your images it works good.

So for the moment selecting the Libraw convertor fixes the problem. Libraw is distributed with ASTAP. You only have to change the setting "Raw conversion" in tab Stack method. It is bottom left of this tab.

Han

[prof7bit]

Yes, libraw is working, I cannot see any obvious disadvantages.

Does it have any influence on the quality at all or isn't it only used to parse the file and extract the bitmaps and ASTAP is doing the actual debayering on the bitmaps after they have been converted to fits?

PS: Is there a document that explains what is actually going on in what order under the hood when stacking raw images, what exactly it is doing when it says "Adding light file", "Calculating pixels σ of light file", "Combining"? Is it doing all these steps on the debayered color bitmaps already, does it debayer on the fly during all these operations because I don't see huge temporary intermediate files being created? I often think about these questions while watching it work for half an hour, trying to imagine what it is actually doing...

[prof7bit]

according to the manpage¹ of dcraw it seems to have an option to turn off the auto flipping:

-t [0-7,90,180,270]
Flip the output image. By default, dcraw applies the flip specified by the camera. -t 0 disables all flipping.

I would suggest this as the most pragmatic solution, I cannot see any benefits in applying the camera orientation to images which are meant for astro stacking and it would avoid a lot of headaches dealing with rotated images and rotated bayer patterns.

---

¹ https://linux.die.net/man/1/dcraw

[han.k]

Good! That works well. I will add it to the next version. Propably this afternoon.

Han