Stacking lunar images using Canon DSLR

[ilove1995]

Hi,

Hoping to get some advise to enable me to stack some images together of the moon using my Canon 600d at prime focus with my 4" MAK.

From what I've read on here so far the recommendation is to take around 120 frames at say 400 iso and exposure at or around 1/1000. My question is should I be setting these values with my camera in movie mode or manual mode?

I've been experimenting with my camera indoors today (as it's still raining) using both of these settings. In movie mode I set the iso and exposure as above and also the movie rec. size to 640x480 (25fps). The files save as movie capture .mov. Should I then be proceeding to convert these files to avi's in order to stack them in registax?

I'm wondering if the correct way is to set the above exposure in manual mode and perhaps use an intervalometer to automatically take shots say 1 per second for a period of 2 minutes or more. I've only attempted to use registax 5 with avi's so far with my webcam but I understand it's possible to process Canon Raw files with PIPP?

Just to confirm I will be using an alt/az mount with goto which I will set to keep the moon in fov.

Any help on this would be much appreciated. Up until now the only stacking I've done is of Jupiter with a webcam. I've taken single shots of the Moon using my DSLR which I am happy with but I've seen better images on this forum of people using the stacking method and I'm keen to give this a go.

Thanks

Al

[JamesF]

I take the images with the camera in manual mode but controlled by my laptop. It would be quite possible to do the same with a remote though.

I don't know that any of the stacking programs are very good at handling RAW files, so I use PIPP to read the RAW files, crop them down to centre the moon in each frame and then write them out as TIFF files. Registax will read TIFFs quite happily. You just select them all from the listing window when you first get Registax to open a file.

James

[Bizibilder]

With your DSLR you may find it easier to take straightforward "still" photo's and stack them. Set the camera in JPEG mode (as the stacking software doesn't like RAW - but you can convert to TIFF if you have enough memory on your computer to enable them to be stacked.) and take at least 60-100 pictures. This tutorial: http://stargazerslou...-solar-imaging/ will help you. it describes Solar imaging but the processing (stacking ) technique is exactly the same for lunar photographs.

You can use the camera in movie mode but the problem is that the camera uses the .mov format. It can be quite tricky to get this into an .avi format that the stacking software will actually be able to read!

As you already have a webcam have you tried this for taking .avi's of the Moon or planets? It will probably be easier to take around 1000 frames with this camera and stack them - the disadvantage being the small area covered with the webcam chip. You may have to take a few overlapping images and then make a mosaic to get a single image of a larger area. Even with an Alt-az mount the stacking software will cope with the slight change in orientation of the image during the time of the exposure.

[ilove1995]

Thanks Guys. By coincidence the settings I have worked out for the moon so far I've got by reading threads you've both posted in the past (which includes Roger's solar imaging tutorial! ).

James, do you use Canon's eos utilities software on the laptop? I'm using it but I don't think it's possible to set the software to take images less than once every 5 seconds. Should I be going about this differently?

With regards to the image I'm trying to capture, I'm basically planning to get a full size image of the moon (forecast is it's supposed to be clear skies later tonight).

Got the inspiration from James's November full moon image as below:-

Thanks

Al

[Bizibilder]

I use Canons utility to take all my solar and lunar DSLR shots. There is a trick to it: Have live view switched ON. This snaps the DSLR mirror open and keeps it open - this prevents vibration on your exposures. Then just click on the manual "button" at the top of the utilities screen and take your pictures. Even doing 120-150 manually does not take long and it is very easy to stop for a few seconds to avoid passing clouds! (Another advantage of having liveview open is you can see the clouds!)

[ilove1995]

Thanks Roger, that's me all sorted for later. If I get a chance tonight I'll post a picture of the moon using this stacking method.

At some point I'd like to attempt a lunar mosaic with a webcam. Got my hands on a Philips spc900 recently, not had a chance to use it what with all the bad weather which is probably my fault getting my hands on new kit.

[Bizibilder]

If you are going to do a Mosaic concentrate on just a smallish area and go fo an overlap of around 30% between frames. I will now prematurely welcome you to the "missed a bit" club .

[ilove1995]

If you are going to do a Mosaic concentrate on just a smallish area and go fo an overlap of around 30% between frames. I will now prematurely welcome you to the "missed a bit" club .

Thanks for the advice Roger!

[JamesF]

James, do you use Canon's eos utilities software on the laptop? I'm using it but I don't think it's possible to set the software to take images less than once every 5 seconds. Should I be going about this differently?

Unlike Roger I don't use the EOS Utilities for controlling the camera. I use APT (AstroPhotography Tool) instead, but I imagine the end result is largely the same. I actually leave a gap of a few seconds between images anyhow because it seemed to help with the stability of the sensor temperature. (APT shows the reported sensor temperature after each image where the camera supports it.)

I started off using Roger's solar imaging tutorial and slowly evolved my own way of working from there for both solar and lunar images. I imagine you'll probably find you do something similar.

I began stacking JPEG images as Roger does, but it always irritated me that I know the RAW files have better quality data yet I wasn't able to stack use them because none of the stacking programs seem very happy processing them. I spent some time trying to convert the RAW files to TIFF, but PIPP eventually caught up with what I wanted to do just as I discovered that the EOS utilities will do the conversion. PIPP has some other useful features though, such as ordering the frames by quality and cropping them down to centre the image making alignment much easier for Registax. Reordering means that it's easy to have an initial scan through the images when they're loaded into Registax and throw out any that are visibly too poor to want to include because they'll be the last ones in the list of files.

So, my workflow goes something like:

1. Capture around 100 to 120 images using APT (I keep both JPEG and RAW images).

2. Process the RAW files with PIPP to crop, centre and re-order by quality, saving as TIFF

3. Load the TIFF images into Registax v6, leaving out any clearly poor images

4. Align the images and then scan through them again throwing out whatever I or Registax decide isn't sufficiently good to include

5. Stack

6. Tweak wavelets etc.

Sometimes Registax 6 can be temperamental in which case I drop back to v5, but my experimentation suggested to me that if v6 did stack the images then it produced a better result than v5 so I always try v6 first.

When I compared my results using this method to the results stacking my JPEGs I felt I saw a significant improvement in the quality of the final image. The best advice I can give you is to draw on what Roger does, what I do, what Steve Ward does and any number of others also do, experiment with the different methods used and see what gives the results you like most. One of the best (and worst things about imaging is that as long as you keep the data you capture you can go back and try different things over and over again.

I'm really pleased that one of my images inspired you to give lunar imaging a go. Seeing Roger's and Steve's images (amongst others) was what inspired me to think more about solar and lunar imaging and it's a pleasure to think that I've done the same in turn.

James

[tingting44]

I use Canons utility to take all my solar and lunar DSLR shots. There is a trick to it: Have live view switched ON. This snaps the DSLR mirror open and keeps it open - this prevents vibration on your exposures. Then just click on the manual "button" at the top of the utilities screen and take your pictures. Even doing 120-150 manually does not take long and it is very easy to stop for a few seconds to avoid passing clouds! (Another advantage of having liveview open is you can see the clouds!)

THIS is a great tip!!! never thought about it before but live view is basiclly like having mirror lock up enabled then right? i wondered why mirror lock up never worked when in live view....DOH! lol

[IanL]

I use BackYardEOS to do the capture. It has a dedicated planetary/lunar mode which records the Liveview image and automatically converts it to an AVI ready for stacking. You can either use the full frame or the 5x zoom mode where the camera outputs a smaller part of the sensor image, which is useful for planetary imaging.

You can easily get 2,000 frames or more, and the large chip size makes big mosaics easier at long focal lengths.

[ilove1995]

Unlike Roger I don't use the EOS Utilities for controlling the camera. I use APT (AstroPhotography Tool) instead, but I imagine the end result is largely the same. I actually leave a gap of a few seconds between images anyhow because it seemed to help with the stability of the sensor temperature. (APT shows the reported sensor temperature after each image where the camera supports it.)

I started off using Roger's solar imaging tutorial and slowly evolved my own way of working from there for both solar and lunar images. I imagine you'll probably find you do something similar.

I began stacking JPEG images as Roger does, but it always irritated me that I know the RAW files have better quality data yet I wasn't able to stack use them because none of the stacking programs seem very happy processing them. I spent some time trying to convert the RAW files to TIFF, but PIPP eventually caught up with what I wanted to do just as I discovered that the EOS utilities will do the conversion. PIPP has some other useful features though, such as ordering the frames by quality and cropping them down to centre the image making alignment much easier for Registax. Reordering means that it's easy to have an initial scan through the images when they're loaded into Registax and throw out any that are visibly too poor to want to include because they'll be the last ones in the list of files.

So, my workflow goes something like:

1. Capture around 100 to 120 images using APT (I keep both JPEG and RAW images).

2. Process the RAW files with PIPP to crop, centre and re-order by quality, saving as TIFF

3. Load the TIFF images into Registax v6, leaving out any clearly poor images

4. Align the images and then scan through them again throwing out whatever I or Registax decide isn't sufficiently good to include

5. Stack

6. Tweak wavelets etc.

Sometimes Registax 6 can be temperamental in which case I drop back to v5, but my experimentation suggested to me that if v6 did stack the images then it produced a better result than v5 so I always try v6 first.

When I compared my results using this method to the results stacking my JPEGs I felt I saw a significant improvement in the quality of the final image. The best advice I can give you is to draw on what Roger does, what I do, what Steve Ward does and any number of others also do, experiment with the different methods used and see what gives the results you like most. One of the best (and worst things about imaging is that as long as you keep the data you capture you can go back and try different things over and over again.

I'm really pleased that one of my images inspired you to give lunar imaging a go. Seeing Roger's and Steve's images (amongst others) was what inspired me to think more about solar and lunar imaging and it's a pleasure to think that I've done the same in turn.

James

Thanks for taking the time to write step by step how you go about imaging the moon James. I took a number of raw images of the moon last night but the weather turned so I had no choice but to call it a night and pack my gear away after taking about 80 frames. When I get some time later today I will check the data but I'm not expecting to see great results as it was blowing a gale with less than ideal seeing conditions.

Taking on board both Your's & Roger's advice I now have a number of techniques to try for imaging when the skies clear again.

So glad I asked these questions now.

Al

[keithatrochdale]

Is PIP only 8-bit for .avi?

Anybody got a 16-bit .avi for .cr2?

[tingting44]

Is PIP only 8-bit for .avi?

Anybody got a 16-bit .avi for .cr2?

i think pipp is 8 bit for color and 16 bit for mono

[JamesF]

Is PIP only 8-bit for .avi?

Anybody got a 16-bit .avi for .cr2?

I've PMed Chris in case he's not seen the posting and asked if he'd answer. Nothing better than getting your information from the horse's mouth

James

[cgarry]

Is PIP only 8-bit for .avi?

Anybody got a 16-bit .avi for .cr2?

If the source data is greater than 8-bit then PIPP will do all its processing in 16-bit mode, only converting the data to 8-bit at the point of writing the output file if the selected output format does not support 16-bit data.

The output formats are as following:

AVI: 8-bit only, colour or monochrome

SER: 8 or 16-bit, monochrome only

BMP: 8-bit only, colour or monochrome

TIFF: 8 or 16-bit, colour or monochrome

There is an AVI codec ('Y16') that supports 16-bit monochrome data, but I am guessing that nobody will have that codec installed on their system so it would be pointless for PIPP to generate a file using that codec when nobody will be able to do anything with it and the SER format already covers this functionality. I do not know of any AVI codec that will support 16-bit colour data (technically 48-bit data I suppose).

What is it that you are looking for exactly?

Cheers,

Chris

[bus_ter]

I'm interested in the whole RAW conversion process. I think we're missing a trick if we're just converting from RAW blindly. RAW is not an image file format. It's the 'raw' data from the sensor of the camera. If you view a RAW file on your computer, you're actually viewing an image file that was created from the RAW file with a set of default options. The jpgs on your camera are also produced from the RAW files (whether you choose to keep the RAW file afterwards or not).

The beauty of working with RAW files is that you can change aspects of the photo before it's created but after it was taken. You can set any value for the white balance and other colour options. You even have some control over the exposure. Once the RAW has been saved as an image (Tif, bmp, jpg etc) you've only got what you can see. With the RAW file you can boost exposure and actually bring out extra details that were lost in shadow, or if an area is 'burnt out' to white, you can turn the exposure down and gain lost details. You can't do this with an image file. All you can do is emphasise detail that's already in the image. By just 'converting' a RAW file into an image automatically is not benefiting from most of the advantages of working with RAW files.

I don't know how to best utilise RAW files in this sort of workflow, but I would suggest opening up the first file in a RAW Conversion software and tweaking the exposure, white balance, Sharpness, Clarity and then applying these settings to all the other RAW files when producing the image files. I think there's a big gain in detail and quality to be made by adding in this step to the workflow before stacking.

[JamesF]

I think either your understanding of RAW file formats (at least the Canon one) is wrong or mine is, as I disagree with some of what you've written.

I disagree that the RAW format is not an image file format. It specifically is a description of the image that appeared on the sensor of the camera. It contains a load of other guff as well and may use a colourspace that isn't the same as the medium used to render the image, but fundamentally it's a datastream that describes an image, just as a JPEG file (or TIFF, PNG etc.) does. In fact, many RAW file formats (including Canon's, I believe) are actually proprietary extensions of TIFF.

You can (kind of) sometimes change the apparent exposure that appears in the final rendering because the RAW file may have a greater dynamic range than the rendered image, but you can't recover data that is genuinely over-exposed, only modify the way in which the rendered image is generated from the RAW image (and JPEGs are very lossy in this respect).

Neither am I convinced that there would be any benefit to modifying the RAW file before stacking because you've already got as much information about the image as you're going to get. In fact, some image transforms (sharpening particularly, I imagine) might well make a mess of stacking and subtraction of darks.

The primary reason for working with RAW files as I understand it is that all the available information about the image is present. By comparison, JPEG has a massively reduced dynamic range and throws away data to achieve compression. In some cases (though I really don't know in the case of DSLRs) it may be that the firmware processing of the data from the Bayer matrix is sub-optimal due to other production constraints.

I'm happy to be persuaded otherwise by a logically reasoned argument however

James

[bus_ter]

OK I guess RAW files are image files in a way. But would you agree that a RAW file, for example, has no white balance? When you open a RAW file to view an image, it gets created by the software and things like the white balance and exposure/dynamic range are selected and used by the software to produce an image (or you can choose the values yourself - one benefit of raw). Also you can't 'open' (or I prefer the term convert into a image) a RAW file unless the software knows about that particular camera and sensor. Such that if Canon introduce a new sensor tomorrow, I will not be able to view any of its RAW files on my computer until I've updated the software so it knows how to interpret the new cameras RAW data. Also different software produce's a different image from the same RAW file. For example I have a Nikon, and if I open a RAW file into Photoshop (using Adobe RAW converter) or Nikons own RAW converter (Capture NX) I get a DIFFERENT image, because each program creates the image in a different way from the RAW file. There are many websites online that compare different RAW converters and comment on the quality, colours and exposure detail of the images they produce. It's commonly accepted that capture NX produces higher quality images from RAW files than Photoshop, but doesn't have all the features of photoshop.

If you agree with everything I said above, you must also agree that calling a RAW file an image format is a loose term at best?

Now I think, but could be wrong, that there is scope to producing better images by taking some control over the RAW conversion process rather than accepting an automatic RAW->TIF conversion?

[bus_ter]

Another way a RAW file is different than an image format is that you can't edit a RAW file. If you open a RAW file into a photo editing program and then alter the image you can't then go and save over the original RAW file. All you can do is save the image file you created from the RAW file as a new file, in an image format (or save all the settings you applied to the RAW data). In the same way, you can't open a Tif or jpg and save it as a RAW file. You would be asking the photo software to convert an image back into the data format a particular camera produced from its sensor. But the image is only one interpretation of the RAW data. To make the image a lot of parameters were decided, such as the white balance. You would have to undo these and get back all the data that was discarded from the RAW file based on the settings, which is impossible as you can't gain back information lost.

I'm confusing myself :-s Maybe I'm even talking rubbish now. Anyway I think I might try imaging the Moon, and I might experiment and see if I can gain anything positive from manipulating RAW file conversions rather than just doing the standard RAW -> TIF conversion.

[cgarry]

I'm confusing myself :-s Maybe I'm even talking rubbish now. Anyway I think I might try imaging the Moon, and I might experiment and see if I can gain anything positive from manipulating RAW file conversions rather than just doing the standard RAW -> TIF conversion.

When I first added support for raw Canon images to PIPP I tried endlessly playing with the conversion parameters in an effort to get a better image. My conclusion was that it really did not make any difference, but I will be interested in what your findings are if you try this.

I have now added the full DCRAW code to the development version or PIPP so it now handles pretty much any raw image format rather than just Canon files, though I have yet to decide how many of DCRAW's long list of controls I should expose in the GUI. For the moment I have kept the options pretty basic in an effort to keep it user friendly.

Cheers,

Chris

[bus_ter]

I didn't know about DCRAW. Does this mean it will work with future cameras?

My testing intention is to take a stack of moon photos and produce 3 sets of images for stacking. 1) the camera produced jpegs 2) an automatic RAW conversion and 3) a manually controlled raw conversion where I have tried to produce the best quality image I can, and then apply the same settings to the whole set of images. Then stack and process all three sets exactly the same and compare the final results.

[cgarry]

DCRAW supports most current cameras (there is a list at the bottom of this page: http://www.cybercom.net/~dcoffin/dcraw/) and is usually quickly updated when new cameras are released. Supporting all these cameras is done by reverse-engineering the raw files as the manufacturers like to keep these formats to themselves, quite an impressive feat by the developer in my opinion. There is only a little bit of work in updating the DCRAW code in PIPP, so PIPP's updates should be able follow DCRAW's updates quite quickly.

I will be interested in how you get on with part 3) of your tests, particularly which setting you find work best for you.

Cheers,

Chris

[bus_ter]

DCRAW supports most current cameras (there is a list at the bottom of this page: http://www.cybercom....~dcoffin/dcraw/) and is usually quickly updated when new cameras are released. Supporting all these cameras is done by reverse-engineering the raw files as the manufacturers like to keep these formats to themselves, quite an impressive feat by the developer in my opinion. There is only a little bit of work in updating the DCRAW code in PIPP, so PIPP's updates should be able follow DCRAW's updates quite quickly.

I will be interested in how you get on with part 3) of your tests, particularly which setting you find work best for you.

Cheers,

Chris

I'll certainly let you know Chris.

I had a quick read through the page and it's quire interesting. Though one thing jumped out that may cause an issue..

"

I shot a raw photo with no light. Why does it appear all noisy, when it should be solid black? No matter how dark an image is?

dcraw's auto-exposure stretches it so that one percent of its pixels appear white. The "-W" option avoids this behavior.

I bracket plus/minus two stops, but all five shots look almost the same in dcraw. Why?

See the previous question. "

This auto exposure stretch won't cause many problems for regular photography, but for Astro use could be significant. I often bracket exposures of Lunar images to get the best detail, but if it's just going to try and make any exposure length look the same then there's probably going to be a loss of quality in the conversion?

[JamesF]

I didn't know about DCRAW. Does this mean it will work with future cameras?

My testing intention is to take a stack of moon photos and produce 3 sets of images for stacking. 1) the camera produced jpegs 2) an automatic RAW conversion and 3) a manually controlled raw conversion where I have tried to produce the best quality image I can, and then apply the same settings to the whole set of images. Then stack and process all three sets exactly the same and compare the final results.

4) as 3), but stack and process to produce the best possible result in each case.

3) only tests what happens if you process the raw files differently before stacking. It doesn't test whether processing them before stacking makes it possible to achieve a better result in the end.

James