DSS vs Nebulosity vs ???

[JMorris]

Does the option '-t 0' (flip image = none) help with the auto rotate?

Yep! That did the trick. No more auto rotate. I'll see if I can find a the 9.17 version of dcraw.

Thanks!

Jim

[JMorris]

Aha! I found a copy of version 9.17 at http://lightzoneproject.org/content/dcraw-917-released and it worked! It reads the wild cards now.

Thanks Ivo! You're great!

[admin]

Awesome!

[Rowland]

I take it that the -W option is not required if the -4 option is used. That is, dcraw -v -r 1 1 1 1 -4 -T -S 32767 -k 0 -o 0 *.CR2 produces an image with no automatic gamma increase.

The -D option extracts pure raw data. How might this apply to our cause for as near as unadulterated data? It seems this is useful for analysis?

A closer look and I think the options I'm seeking are $dcraw -v -d -4 -T -o 0 *.CR2 which should produce a 16bit linear tiff, Bayer, monochrome, no auto gamma increase and no black point set. Not sure if this is the PI preset - away from computer a few days. Images aee converted to RGB at deBayer, which saves memory and simplifies calibration.

[admin]

I take it that the -W option is not required if the -4 option is used. That is, dcraw -v -r 1 1 1 1 -4 -T -S 32767 -k 0 -o 0 *.CR2 produces an image with no automatic gamma increase.

The -D option extracts pure raw data. How might this apply to our cause for as near as unadulterated data? It seems this is useful for analysis?

A closer look and I think the options I'm seeking are $dcraw -v -d -4 -T -o 0 *.CR2 which should produce a 16bit linear tiff, Bayer, monochrome, no auto gamma increase and no black point set. Not sure if this is the PI preset - away from computer a few days. Images aee converted to RGB at deBayer, which saves memory and simplifies calibration.

Yep, you can leave the RAW files bayered and let another program take care of it, if you trust it to do a good/better job (you will have to make sure you get the bayer matrix right).

[Rowland]

It would be better to control all the dcraw outputs where possible. Calibration sits between the dcraw linear and deBayer outputs and the -q 0 option would be called separately following calibration. The monochrome thing, to save memory requires this as far as I know.

[admin]

Calibration sits between the dcraw linear and deBayer outputs

I think that debayer is done first and calibration later (I cannot see the source for any program, but that is definitely how I would do it!).
As you will notice when zoomed in, the monochrome images aren't really usable as a calibration source yet since they 1. lacks colour, 2. contains a 'checker' pattern.

EDIT: Correction (thanks Rowland!);

Bias calibration of the light frames does not require debayering.
Dark calibration of the light frames does not require debayering.
Flat correction of the light frames does not require debayering.

Debayering of the light frames is only needed when aligning and stacking commences.

That said, debayering the master frames (and all light frames) before calibration should not hurt (when using a simple interpolation algorithm, like bilnear interpolation, anything 'smarter' can start introducing noise/artifacts that stacking can no longer fix from a mathermatical point of view). For example, some people actually like to apply a Guassian blur to their master flat, since no fine detail/noise should exist in a flat, only coarse detail and gradients - this way no noise is introduced by the master flat when it is applied to the lights. Applying a Gaussian blur is obviously hard (though not impossible) when the data is still bayered like this.

[Rowland]

Interestingly, I understand that is what the PI Batch Preprocessing script does. Calibration is completed with the mosaic in place. However, I am now uncertain whether this applies to calibration frames as well. Will report back

[Rowland]

These are the PI Bayer Monochrome No Blackpoint options $ dcraw -D -k 0 -t 0 -o 0 -4

It is worthwhile remembering that preprocessing scripts are also designed with 16bit OSCs in mind - linear data.

The option -d that I posted previously is obviously not correct. I have added -v as well as -T, to convert to tiff - $ dcraw -v -D -k 0 -t 0 -o 0 -T -4 should produce a Monochrome Bayer no blackpoint correction .tiff file as close to the RAW data as can be.

In view of the truncation of data by bias subtraction of dark frames, as well as firmware manipulation of RAW data, scaling is not recommended and I think, pixel rejection can be ignored. Just convert and integrate calibration frames warts and all. Pixel rejection is necessary however, for removing satellite trails and so on, but not for any other cosmetic reason, as far as I can tell - guess that's open to debate - the RAW data has been manipulated by the camera and, what have we really got? A lot of cleaning up goes into providing a RAW file that translates easily into a pretty picture - so I think, it's pretty much OK anyway and no need to subtract further from it.

Interestingly, the recommended manual PI preprocessing for DSLR data is to use the -r 1 1 1 1 option. This is not favoured by some, however, rather than indicating that monochrome is personal preference, the argument has been presented authoritatively - by well meaning people - as the preprocessing default, which has generated confusion. The main advantage of monochrome calibration is memory and speed.

[admin]

Very interesting stuff Rowland and thanks for posting this!

Pixel rejection is necessary however, for removing satellite trails and so on

Yep, a stacking algorithm based on statistical rejection should take care of removing trailing, and if the user has properly dithered in between frames, dead or hot pixels will also have been taken care of.

Interestingly, the recommended manual PI preprocessing for DSLR data is to use the -r 1 1 1 1 option. This is not favoured by some, however, rather than indicating that monochrome is personal preference, the argument has been presented authoritatively - by well meaning people - as the preprocessing default, which has generated confusion. The main advantage of monochrome calibration is memory and speed.

Makes sense to me!

(to be clear; the -r 1 1 1 1 option is to make sure the image stays non-whitebalanced)