Mosaic with M42

[sixburg]

I'm working on an 8 panel mosaic the M42 area.  Since M42 will be treated as an HDR panel, how then do you do the steps for mosaic creation given that after HDR processing the M42 panel will no longer be linear?

I've tried various combinations with very poor results especially w.r.t. linear fit / frame adaptation.  The panels around the HDR panel are transformed to near darkness.  Thanks for your help.

[pfile]

should still be linear after HDRComposition. HDRMultiscaleTransformation is a different story though, that's used on stretched images to do tone compression. i assume you are referring to HDRComposition here.

[sixburg]

Thanks, I wasn't very clear.  Yes, I understand that it's still linear after HDRC.  Once done you have a "raw" hdr panel, M42 in this case.  But it needs HDRMT treatment which will result in a non-linear image.  So how do you use this in a mosaic when the mosaic tools require (prefer?) linear images? 

I tried to use a range mask to isolate M42 and perform HDRMT on it, but the core was lost.  As an individual frame, however, HDMRT works on it just fine. 

So the question remains how to integrate a non-linear panel into a mosaic which requires non-linear data?  I'd love to leave everything linear, but I have to do HDRMT on the panel before integration. 

[pfile]

just build the mosaic out of the f64 HDR linear files, then process as usual when the mosaic is finished…

however, i think i'm missing something still about what you are doing.

rob

[sixburg]

Hmmm...maybe I'm missing something simple.  Of the 8 panel, I only intend to use HDRMT on one of them with the understanding  that one one requires it.  The areas surrounding m42 are relatively low in signal.  So the way I understand it right now is that 1 of my 8 panels will get HDRMT.  As soon as I do that, it is no longer linear.  So, I'd have to create the mosaic first with all linear panels and then try to do HDRMT on just the area that needs it.  Does this sound right?  Now, to figure it all out. 

[pfile]

you should be able to do HDRMT on the whole, finished mosaic. you can create a mask to protect the other parts of the full image when it comes time to do the HDR transform.

so...

1) create all the panels for the mosaic (stacking, DBE)
2) create the "special" panel by stacking and DBE of the main exposure, and just stacking of the bracketed exposures (probably don't need to do DBE since just a small part of the bracketed (short) exposures will come in to the final product.)
    2a) do HDRComposition of the special panel images
3) stitch the mosaic together
4) process the combined mosaic image; when it comes time for the HDR transform, mask as described above.

the only wrinkle here i can see is that the panel created from HDRComposition will probably be f64. i am not sure what StarAlignment will do when it merges that panel in with the rest (convert everything else to f64 or downconvert the f64 frame to f32?). in theory you could represent all your other panels as f64, but that may result in huge files. i suppose you can convert the HDR panel to f32; it may still 'fit' in f32.  i think HDRComposition can be told to generate f32 and IIRC it would warn you if f32 can not contain the entire dynamic range.

rob

[sixburg]

I was able to do some testing and so far the solution to this elude me.  I've attached a screen shot that shows what I'm getting so far.  Any input is appreciated.  To explain:  column 1 represents raw panels #5 over #6.  Column 2 is the STF version of each frame.  The top STF'd frame, panel #5, is the HDRComposition frame.  Panel #6 is just a regular stack (the level of noise in this unprocessed image is exaggerated in part by the aggressive STF, but it's still surprising as it consists of 21 total frames of 12x20 minutes and 9x15 minutes integrated with WSC...also of note is a problem on the top edge which is unfortunately a bright star just off camera which I thought I could deal with in post-processing somehow...later). 

Column #3 is the result of performing StarAlignment | Register/Mosaic with Frame Adaptation and the final column is with STF applied.  Already things do look right.  Note that I did convert the HDR frame to 32f and the results at this stage of processing look the same.  The merge mosaic processing resulted in a final image that looks nearly identical to the the one in column #3. 

I also tried to add this problematic panel #6 to another part of the mosaic.  In each case it exhibits this greyed out look to it.  There is something wrong with this panel relative to the others....

In case you want to see the actual files a Skydrive link is included.  I also included the combined panel a1-a4 to demonstrate that the processes in PI are working well as demonstrated by this very preliminary result (GMM has not been done on this part yet, but I know it's all good since I did it on just panels 2 and 4 which would be just B33 and adjacent areas). 

Aquisition details on the panels:  all acquired with FSQ106iii @ f/5, Mach1GTO, QSI593wsg, Astrodon 5nm HA, -15C and -25C depending on the weather with ~24 darks, ~12 flats, >50 bias.  All panels at least 4x900 and 6x1200 (the target is to get to at least 16 total frames per panel to keep the exposures nearly the same and to have enough to combat noise).  Panel 5 with M42 is 5x60, 5x300, 6x600, 6x1200. 

http://sdrv.ms/Hp2L9c

I would just choose another tool (PS CS6) to do this, but believe it or not I don't know how to do AP processing in PS as much as I do PI since I decided to start out with PI from day 1.  I know enough about it to pull this off, but would rather get this tool to do what I know it should be able to do. 

Thanks for looking.

[pfile]

was frame adaptation run when constructing a1a2a3a4?

can you post a1 - a4 separately?

rob

[sixburg]

Hi Rob,

Yes I used frame adaptation on a1-4 and also took it all the way through GMM without much of a problem.  What I'm beginning to figure out is that merely taking the same integration times is not enough to get the panels well-matched.  Evidently the low signal panels will need more integration or I need to do a LinearFit or something.  I don't necessary like the guesswork here, but again, I could be missing something fundamental. 

This link goes to the same skydrive folder but a1 through a4 are included separately.  They are WSC stacks with DBE applied and nothing else. 

http://sdrv.ms/1aTqENd

Thanks for looking.

Lloyd

[pfile]

yes as far as i can tell the signal is just too low in that last panel. it's true that equal integration time is not necessarily going to cut it. i tried a bunch of tricks linearly shifting the data, but no luck - i think maybe that really bright spot in the last panel is fooling the frame adaptation.

but overall the frames should have been matched better even without GMM so i'm not sure what's going on, i will have to play with it a little bit.

rob

[pfile]

now skydrive is asking me to log in to download these files… yesterday it worked without a login. i don't have a skydrive account…

rob

[sixburg]

Here's a new link that should be enabled for public access

http://sdrv.ms/17sW3uV

[sixburg]

I think you may be right about that bright spot on panel 6.  About half of the frames for panel 6 are shifted away from the bright start that I thought was causing the problem.  What I did was shoot the initial batch of panel 6, saw the problem, and then shifted the next batch of frames 'closer' to M42 thereby moving the bright star further into the frame.  This reduced the brightness, but not by the amount I had anticipated.  I stacked each batch together and cropped away the brightest area while ensuring that the mosaic could still match up to panel 5.  Obviously this didn't work completely and I'm not sure why as I made sure to avoid the bright stars at the intersection. 

I'm going to clone out the bright area as a way to test if the bright area is fooling the frame adaptation.  Note that if you combine panel 6 with panel 4, it's neighbor to the 'left' you get the same dimming of panel 6. 

[sixburg]

I tried the experiment of cloning out the bright parts of panel 6 with decent results, but not great (screen shot attached).  My hypothesis is that frame adaptation is not well switched to mosaics with widely varying intensities in the adjacent panels.  Both the bright spot on panel 6 (which shouldn't even be there) and panel 5 with M42 itself are way more intense than the surrounding panels which leads to the issue.  I can try this with terrestrial programs like Photmatix and CS6 to see what happens.  Unless there's a clear solution to this I'll take a pass on what for me is a very ambitious mosaic project.  At least the B33 area looks like it's going to work out. 

Another experiment will be with non-linear images w/out frame adaptation...

[pfile]

yes in fact when working on your files i did stretch them to comparable levels and build the mosaic from the stretched files and it did work fine. the issue there is precisely matching the statistics of the stretched frames. with some care and careful use of the Statistics process i'm sure this could be done.

georg would have to comment how GMM works against nonlinear frames and if it's able to match the brightness. i'm not sure if GMM is only working on the transitions or across the entire frame to match brightness.

i think this project should be doable in PI. i have certainly done a big mosaic of this area but the individual panels were much bigger, which may have helped me dodge the brightness issues you are seeing. i only did 3 subs per panel and it was more of a test than anything; i did not use GMM and in fact the panel brightness is a little off.



rob