*Sky & Telescope Illustration by Casey Reed
Privacy Policy | Contact Us | Affiliates | About Us | Participant Sites
International Year of Astronomy | American Association of Variable Star Observers (AAVSO)
Privacy Policy | Contact Us | Affiliates | About Us | Participant Sites
International Year of Astronomy | American Association of Variable Star Observers (AAVSO)
Hello!! After some succesful runs of the sample data and some more (finally having results!), I went back to the IRIStutorial to clarify the text more. I did mainly text and layout corrections and additions trying to make clear what is necessary and what is not. Check out the corrections if you want (Itried to be as much as possible analytical to the log revision) and of course any suggestions are welcomed! Best wishes, Grigoris
Hi!! I just added step 3dd which has to do with the procedure to extract a master-flat in case flat-field images were not taken. I had written by mistake that the only thing needed is just to take 3 star-field images, rename them and put them to the make-flat box, which is not of course right. You need to do some processing first and this process has been written. Perhaps this can be useful in other cases also ! regards, Grigoris
Hi all, I also checked the other way that exists in IRISto separate RGB from raw. It's: "load raw file", go to "digital photo", make "CFA conversion", then "RGB separation" (I think this is the menu in English, my version is the french one, Idotranslate!) This generates three FITfiles supposed to be R,G,B. I did check it for the Canon G9 ( that is an RGGB case) the files are well the right color ones, without further processing, including the 128 Canon's offset. Well usable. I also did check it for a D70s Nikon, the colors are not right ! B and R are reversed. Obviously IRISdoesn't properly manage the pattern info given by dcraw.exe (used for rawimage files decoding by IRIS) Users of DSLR other than Canon RGGB types should be very careful with IRISand check the colors they get. Yours truly, Roger
Hello Heinz, Yes, there is a problem with the Bayer pattern in this tutorial. IRISis not conventional on that aspect, the order of colors is not as usually denominatedstarting from the upper left corner of the Bayer group and reading it left to right and top to bottom. This is due to the fact IRIS doesn't put the origine of the picture as (0, 0) at top left but (1, 1) at bottom left. The number of lines of pictures from DSLR of various brands beingodd or even the resultingorder of the Bayer pattern is unpredictable in IRIS and the color order ofC1, C2, C3, C4 could be anything depending brand. For Canon450D and Canon G9 Ifound GBRG (instead RGGB), for Nikon D70sI have GRBG (instead BGGR).Any DSLRtype needs to be tested under IRIS to determine it. Yours truly, Roger
Hi Roger ! How can you examine what type of Bayern pattern IRISidentifies? Regards, Grigoris
Hello Grigoris, I think you can access the tutorials preps. I did explain this under "Camera Characterization" point6, "Bayer pattern". The only reliable way is to use images having known color elements to identify what color order IRISis using in each specific case. In the epsilon AUR star field it's easy to do this using eta and zeta that are strongly blue and strongly red. From notes from Dave Coffin (dcraw.exe being used by IRIS) near all DSLR/DSC with raw modehe analysed (near 400 types !)have RGB filters using either of the basic configurations RGGBBGGRGRBGGBRG. Only a short list ofoldPowerShot involves more specific patterns. Another aspect I would note is that the second way to separate colors using the "CFAconversion" command is not my prefered. The reason is that it goes through the Bayer interpolation process of dcraw.exe, any such interpolation could affect the original ADC output. There are number of interpolation methods available in dcraw and I have no idea which is used by IRIS, some are very tricky and would be a serious problem. I would much prefer "split_cfa" that just separate the original ADC values. Yours truly, Roger
> Another aspect I would note is that the second way to separate colors using > the "CFAconversion" command is not my prefered. The reason is that it goes > through the Bayer interpolation process of dcraw.exe, any such interpolation > could affect the original ADC output. The tutorial instructs users to set the interpolation method setting to "linear" (and to disable white balancing) which should be fine in my opinion provided this is properly passed on to dcraw by IRIS. Maybe this can be tested somehow. The procedere would be so much easier without having to tell people that the split_cfa depends on their camera brand. As noted above, even the cfa to rgb conversion seems to result in unexpected outcome sometimes, but if the only error mode is that the blue and red channels are swapped, we will be fine, as those channels are abandoned anyway and we use the green one only. CU Heinz
Hello Heinz, Regretfully I have not been able to identify any logic in the way IRISmixes colors ! In a first approach I did think I got it but next I found case that doesn't fit... At time being I can't say if the issue is different for split_cfa or cfa_conversion.Withboth functionsthe green doesn't move in cases I can test. I can only test the RGGB and BGGR configurations, I have no GRBG or GBRG picture at hand. In the process most of you use, only thegreen is considered but there are other ways thatinvolve at least blue and green andpossibly thered. For what concerns interpolation, if you are confident with "linear" I am ok. The bi-linear interpolation should not generate much troubles. But I don't understand what IRIS is doing here. If that commandis passed to dcraw the RGBconfigurationis determined by dcraw and theerror shall not occur. At that point I realize the cfa_conversion probablydoesn't involve dcraw. Now we can imagine that in case of opposite diagonal we get... a mix of red and blue ! instead green. Personnaly I prefer to use the pure raw data from the ADC for my own processing (I do not use IRISbut my own functions under DylogAPL) direct from the -D option of dcraw. Another aspect is that the interpolated files are four times largerand not so easy for old computers... Yours truly, Roger
I see your point... I even kind of like the fact that the extracted green image is enlarged to the original dimensions because IRIS allows to perform the aperture photometry measurement only at 1:1 zoom level, and if you have a rather high dpi monitor, even defocused stars can appear quite small. Anyway, the "original ADU count" argument is a strong one. Ok, but if we want to do without cfa -> rgb conversion, we have to re-arrange the order of steps, right? I don't think that IRIScan do meaningful stellar registration and stacking on CFA images, or can it? I would think that even some field rotation is applied.... So working just with CFA would imply: a) import RAW images as CFA b) Calibrate images c) batch-separate the green channel (actually 2!!), using split_cfa2 I guess d) register and add the green channel images so color extraction and stacking would be swapped in this workflow compared to the current tutorial. Right? CU Heinz
Hi Heinz, I had some more thinking about what IRIS is doing at CFA _conversion stage. In fact the output data is not compatible with the dcraw options. That means IRIS uses dcraw for decoding raw files to CFA but next it uses its own processing for doing the RGB interpolation. By the way it doesn't use the pattern information provided by dcraw.
Next I shall apologize, I made a mistake selecting the DSLR type when I tested "CFA_conversion" for my old Nikon. In fact it works properly like the Canon's. But there are number of DSLR/DSC types that are not available and for which a color inversion is possible. The issue in CS is it involves a large public that would use many different brands and types. That's not the case in the amateur astronomy community as most of them use Canon's types.
People having DSLR/DSC being not listed should make a test. It's simple, they have to make an image with RGB color patches and check the cfa_conversion command. Next they could try another camera type from the list if there is a problem (for cfa_conversion only) It would be interesting to find examples of the four possible patterns in this list, I know only two cases of them. I agree it's probably not possible to properly register images in CFA mode. Personally I do not stack such very large images ( 12 Mpix means 2 x 72 MB ! at least) for photometry, It takes too much time, it's faster to directly analyse each image (just some clicks in each depending the number of stars you consider) Maybe its' different for people having powerful computers. Anyhow my own software do it automatically on many stars, I use IRIS only occasionally for some testing and comparison. Analysing each image also provides the possibility to calculate the true SD for each star. I consider it very important as a guidance for optimizing the overall process, it's also an important info for a possible user of the results (Theoretical SNR calculation is not so convincing... )
Interpolation: As I said before, for photometry, I do prefer the simple CFA separation because itfits well my own process and software and is no issue. But if converting is easier for others it's a viable solution provided it's a bi-linear interpolation. I will make some comparative tests within a couple of days.
Yours truly,
Roger