Master after WBPP is green and I can't fix it.

M

MCox

New member
Hello community.

First post here and I imagine it wont be my last.

I'm a fly fishing guide who has taken up the hobby of astrophotography, I'm fairly new to the hobby and am learning mostly from the University of Youtube.

I'm using a Sony a7iii and a sony 200 to 600mm, on a SA GTi tracker.

I've gotten fairly good pictures of Comet Pons_Brooks, but I'm struggling horribly at processing.

Mainly, with WBPP I suppose.

Every time I run WBPP, my master frame and my light frames of the comet are completely green. I can see a fair stacked image but it's all on the green channel. For the life of me I can't figure out how to get the merged, aligned RGB master after WBPP.

I'd be most appreciative of any help and assistance.
 
It sounds as though you have not colour calibrated the image. Raw images from OSC cameras always have a strong green cast (because the sensor is most sensitive to green light). The SPCC colour calibration process corrects this colour (by cross-referencing recognised stars in the image to a spectrophotometric catalogue - so each catalogue star in your image is effectively a colour calibration reference point). Choosing a comet as a target makes things harder - you would be better advised to try non-moving targets to develop basic processing techniques. It doesn't help that the comet does have an intrinsic green colour itself.
 
I have not color calibrated. But all my individual frames look fine color wise.

While the WBPP was doing it's thing, several times it stopped to get a confirmation about plate solving. I have no information about the plate solving numbers so I licked cancel. IS this what youre referring to by the SPCC process?

I know what your saying about the green hue.....but this is not that. I mean it's like only the green rgb channel is coming through. I can still see the comet and stars, but everything is green......much like my Avatar with the big M in it.

Is there anyway to manipulate it to allow it to by pass color adjustments based on plate solving and to just stack the images as they are?
 
In addition you can get an idea of what the file should look like if you do an unlinked stretch in the Screen Transfer Function module. There’s a shortcut in the toolbar for it that looks like a radioactive symbol. If you hover over it you’ll see what key to hold when clicking the icon to more easily get an unlinked stretch. This is temporary and is used to give you an idea of what you captured.

Then you’ll want to generally do a gradient correction and then the SPCC process for color calibration. There are other ways to get there as well but these are simpler ways.
 
The plate solve is coming up because it wants you to tell it where you were pointing. There is a lookup to help you find a target’s coordinates. The same function can be found with the ImageSolver script. It is a requirement to use the SPCC process. I don’t have much time but there are a lot of videos on YouTube on Pleiades’s official channel which go through the SPCC process and other important bits.
 
MCox said:
I have not color calibrated. But all my individual frames look fine color wise.

While the WBPP was doing it's thing, several times it stopped to get a confirmation about plate solving. I have no information about the plate solving numbers so I licked cancel. IS this what youre referring to by the SPCC process?

I know what your saying about the green hue.....but this is not that. I mean it's like only the green rgb channel is coming through. I can still see the comet and stars, but everything is green......much like my Avatar with the big M in it.

Is there anyway to manipulate it to allow it to by pass color adjustments based on plate solving and to just stack the images as they are?
Click to expand...
It's an issue when you're using a "dumb" tracker and an ordinary camera that no pointing information is included with the image. The easiest thing is to submit one of your images to astrometry.net and get back the plate center coordinates and the pixel scale, which you can then manually enter in the image solver. This is a very important step. A number of processes depend upon a solved image. And in your case, the most important is SPCC, which you certainly do not want to bypass. It is key to almost all color processing.
 
MCox said:
I have not color calibrated. But all my individual frames look fine color wise.
Click to expand...
Do you mean your individual raw frames? Your raw frames should not be coloured at all - they should be greyscale CFA files. If your raw (.arw) files are loaded as coloured RGB files, then you probably have the wrong raw file input settings:
1710683693498.png

You can get all the correct settings by selecting the "Pure Raw" button.

If you are not loading raw CFA files, almost all of the PI calibration processes, and almost all of the advice you get on the forums will not be appropriate!
 
fredvanner said:
Do you mean your individual raw frames? Your raw frames should not be coloured at all - they should be greyscale CFA files. If your raw (.arw) files are loaded as coloured RGB files, then you probably have the wrong raw file input settings:
View attachment 22419
You can get all the correct settings by selecting the "Pure Raw" button.

If you are not loading raw CFA files, almost all of the PI calibration processes, and almost all of the advice you get on the forums will not be appropriate!
Click to expand...
But this doesn't change the fact that opening an individual raw file in PI results in an RGB image. So raws will look "right" when examined individually but will still be gray CFA files inside of processes.
 
cloudbait said:
But this doesn't change the fact that opening an individual raw file in PI results in an RGB image. So raws will look "right" when examined individually but will still be gray CFA files inside of processes.
Click to expand...
Are you sure? I thought that format preferences controlled all contexts for opening a file (including within processes and scripts). This is certainly true for .fits format preferences.
 
fredvanner said:
Are you sure? I thought that format preferences controlled all contexts for opening a file (including within processes and scripts). This is certainly true for .fits format preferences.
Click to expand...
I have the same raw setting you show above, and when I open a raw in PI it is automatically debayered. But all my processes handle them properly as CFA files.
 
fredvanner said:
Are you sure? I thought that format preferences controlled all contexts for opening a file (including within processes and scripts). This is certainly true for .fits format preferences.
Click to expand...

not entirely. many processes that touch disk files directly support "format hints" which will override whatever is set in the preferences. so you can for instance tell the RAW decoder to debayer DSLR files for you, but ImageCalibration (and by extension WBPP) can still use format hints to cause the files to be opened without debayering. if you open ImageCalibration and reveal the format hints section, you'll see what's there by default.
 
pfile said:
not entirely. ...
Click to expand...
That could explain some things, but..
cloudbait said:
I have the same raw setting you show above, and when I open a raw in PI it is automatically debayered. But all my processes handle them properly as CFA files.
Click to expand...
With the raw settings as in my screenshot, my raw images always open as CFA, so this still looks a bit of a puzzle. If images open as RGB even when the preferences ask for CFA, how do you just open a raw image as CFA. If this varies from system to system then the OP needs to sort out what his system is doing - since this could be a source of real confusion.
 
I don't have a Sony camera, but I just tried opening an .arw file, and it opened as raw CFA on my system (as I would hope and expect with my settings).
 
cloudbait said:
I have the same raw setting you show above, and when I open a raw in PI it is automatically debayered.
Click to expand...
Simply opening a raw file (I've tried .arw and .cr2) using the PI "Open" menu command opens as CFA on my system (with the settings as posted in #7 above). I wonder where your system is getting the "order" to debayer from?
 
fredvanner said:
Simply opening a raw file (I've tried .arw and .cr2) using the PI "Open" menu command opens as CFA on my system (with the settings as posted in #7 above). I wonder where your system is getting the "order" to debayer from?
Click to expand...
No idea. If I drag a single CR2 file onto PI, it opens as RGB. If I process a bunch of them from the same set with WBPP, they are calibrated and debayered as I'd expect. I looked through the preferences and there's no obvious setting for that.

In any case, though, getting back to the original issue here, it seems likely that there is no problem except for the failure to plate solve and run SPCC.
 
Last edited:
I hadn't tried dragging the file in - but I have now and I get the same effect. I really don't understand this. Are there some "format preferences" other than the ones in the Format Explorer that control the "Open" command?
Because for years now all my capture has been it fits format I haven't actually used raw format for ages, so this is not something I usually have to worry about.
 
I'd really like to get to the bottom of this, since there is so much scope for inexperienced users to get completely bamboozled if the app doesn't behave consistently. Perhaps a few other users could test this behaviour: with raw format preferences selected to the "Pure Raw" settings (in Format Explorer "Edit Preferences"), does a "camera raw" image opened in PI load as greyscale CFA or debayered RBG?
 
fredvanner said:
I hadn't tried dragging the file in - but I have now and I get the same effect. I really don't understand this. Are there some "format preferences" other than the ones in the Format Explorer that control the "Open" command?
Because for years now all my capture has been it fits format I haven't actually used raw format for ages, so this is not something I usually have to worry about.
Click to expand...
I only very rarely deal with raw images, either. But IIRC this has been the behavior on my system forever, through many PI releases. Maybe something to do with rawlib and how/if it understands the CFA pattern? My raws are coming from a Canon 7D.
 
cloudbait said:
Maybe something to do with rawlib and how/if it understands the CFA pattern?
Click to expand...
But you and I now have the same rawlib installed, and I have tested a Canon .cr2 image - so I can't see where the different behaviour can be coming from.
... unless it is a rawlib difference between different platforms...
 
fredvanner said:
But you and I now have the same rawlib installed, and I have tested a Canon .cr2 image - so I can't see where the different behaviour can be coming from.
... unless it is a rawlib difference between different platforms...
Click to expand...
Or unless the internal details of CR2 files vary between cameras.
 
You must log in or register to reply here.
Back
Top