-
Notifications
You must be signed in to change notification settings - Fork 0
/
gallery.cfg
3136 lines (2864 loc) · 140 KB
/
gallery.cfg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[DEFAULT]
geom_sqr : 512x512
geom_wide : 896x512
[binning.dmcopy.sky.size]
title : Bin Event File to Image; Specify Bin Size
requires: acisf06934N002_evt2.fits
provides: 6934_sky_binsize.fits
commands: dmcopy "%(requires)s[bin x=3500:4500:2,y=3500:4500:2]" %(provides)s clob+
outfile : 6934_sky_binsize.fits
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
One of the first things Chandra users want to do is to bin their
event file into an image. The <tt>ds9</tt> application does this
automatically when you load the event file; but when you need to
run tools such as <ahelp name="wavdetect" tt="1"/> or <ahelp name="csmooth" tt="1"/>
you will need to bin the event file into an image yourself using <tt>dmcopy</tt>.
</p>
posttest : <p>This is a simple example showing the <tt>[bin ]</tt> syntax
where the <tt>X</tt> and <tt>Y</tt> columns are binned independently
using the <tt>min:max:stepsize</tt> syntax.
</p>
[binning.dmcopy.sky.nbin]
title : Bin Event File to Image; Specify Number of Bins
requires : acisf06934N002_evt2.fits
provides : 6934_sky_nbins.fits
commands: dmcopy "%(requires)s[bin x=3500:4500:#512,y=3500:4500:#512]" %(provides)s clob+
outfile : %(provides)s
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext: <p>Rather than specify bin size you can specify number of bins.</p>
posttext : <p>This example produces the same output as
<cxclink href="#binning.dmcopy.sky.size">the
example above</cxclink>, but rather than specifying the bin size we
specify the number of bins.
</p>
## TODO: subpixel, non-integer
[binning.dmcopy.sky.filt]
requires : acisf06934N002_evt2.fits
provides : 6934_sky_circle.fits
title : Bin Event File to Image With Filtering
commands : dmcopy "%(requires)s[sky=circle(4096.5,4096.5,500)][bin sky=2]" %(provides)s clob+
outfile : %(provides)s
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
Typically, users will also need to apply various filters to their datasets
when they are binning. In this example we apply a circular spatial filter to the
event file as the data are being binned.
</p>
posttext :
<p>
In this example, the individual columns X and Y ranges have been replaced
with the simplified syntax <tt>[bin sky=2]</tt>. <tt>sky</tt> is the
name of the <em>vector column</em>, composed of the X and Y columns.
</p>
<p>By default the image shrinks to a bounding-box around the filter.
Values outside the
region are set to 0. This behavior can be changed using
<ahelp name="dmopt">DM options</ahelp>.
</p>
[binning.dmcopy.sky.fov]
title: Bin Event File to Image With FOV Filtering
requires: acisf06934_000N002_fov1.fits acisf06934N002_evt2.fits
provides: 6934_s3.fits s3.fov
commands : dmcopy "acisf06934_000N002_fov1.fits[ccd_id=7]" s3.fov clob+
dmcopy "acisf06934N002_evt2.fits[sky=region(s3.fov),ccd_id=7][bin sky=2]" 6934_s3.fits clob+
outfile : 6934_s3.fits
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
Another common spatial filter is to apply the Field of View file (FOV)
to establish the edges of data within the image.
The FOV file is a FITS REGION format file that contains at least 1
row per CCD.
</p>
postext : <p>
In this example we start by running <tt>dmcopy</tt> to select the FOV
for just CCD_ID=7.
Then we run <tt>dmcopy</tt> using that file as input to the <tt>region()</tt>
filter. The <tt>region<tt> syntax extracts the region from an external
file. This same syntax is used with ASCII format region files that users
may create in <tt>ds9</tt>.
</p>
<p>
The syntax to copy the event file requires 2 separate operations.
First the <tt>sky=region(s3.fov)</tt> selects only the events that
are spatially located within the Field of View. However, due to the
way Chandra dithers there will likely be events from neighboring
CCDs that are imaged within the S3 FOV for some fraction of time
during the observations. (Another way to say this is that the
chips overlap on the SKY due to dither). Therefore to get only
the data on S3, we have to add the ccd_id=7 filter.
Why not just use that filter? The spatial extent of each chip
is not stored in the event file. Without the sky=region() filter, the
<tt>[bin sky=2]</tt> command would produce a much, much larger 4096x4096
image (covering the entire image space). This is why we need to have both.
The sky=() sets the spatial limits of the data, and the ccd_id filter selects the
subset of the data to include.
</p>
[binning.dmcopy.sky.flux]
title : Weighted Binning
requires: acisf06934_000N002_fov1.fits acisf06934N002_evt2.fits s3.fov
provides: fluxed.evt 6934_flux.fits
commands: eff2evt "acisf06934N002_evt2.fits[ccd_id=7,energy=500:3000]" fluxed.evt clob+
dmcopy "fluxed.evt[sky=region(s3.fov)][bin sky=2;flux]" 6934_flux.fits clob+
outfile : 6934_flux.fits
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext :
<p> We do not always bin to accumulate counts. We can use weighted binning to
accumulate other things like <em>flux</em>.
</p>
postext : <p>
In this example we use the <tt>eff2evt</tt> tool to assign a flux
to each event on ccd_id=7 in the 0.5 to 3.0 keV range. Only those events
are stored in the output <tt>fluxed.evt</tt> file.
</p>
<p>
We then bin this into an image as we've seen before; except that we
now add an optional weighting argument. The <tt>[bin sky=2;flux]</tt>
tells dmcopy to bin the data into an image, but rather than count
each row as 1 count, it accumulates the values from the
<tt>flux</tt> column in the fluxed event file.
</p>
<p>
This can be a quick way to get a <strong>very</strong> rough
estimate of the energy flux. This technique can be
very inaccurate when there are low number of counts or if
made in very narrow energy bands.
</p>
[binning.dmnautilus]
title : Adaptive Binning
requires: 6934_s3.fits
provides: 6934_abin.fits 6934_mask.fits
commands : dmnautilus 6934_s3.fits 6934_abin.fits snr=20 outmask=6934_mask.fits clob+
outfile : 6934_mask.fits 6934_abin.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -cmap load $ASCDS_CONTRIB/data/16_ramps.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
Usually we work with images that are binned such that all the pixels
are the same size (and most often, are square). There are
applications where having the data binned on an irregular or adaptive
grid can be useful. There are many approaches to compute such a
grid, in this example we introduce the CIAO tool <tt>dmnautilus</tt>.
</p>
<p>
<tt>dmnautilus</tt> uses a <em>quad-tree</em> algorithm. It works by taking
the image and dividing it
into 4 approximately equal sub-images. It computes the signal-to-noise (SNR)
for each of the sub-images. If the SNR is above the desired threshold,
then it further subdivides that sub-image in four. If the SNR is
below the threshold, then the process stops for that sub-image tree.
The result is a grid where each cell ("pixel") will have at most
a SNR equal to the input threshold.
</p>
posttext : <p>
The image on the Left shows the grid that <tt>dmnautilus</tt> computed, the
<tt>6934_mask.fits</tt> output file. Each of the cells in the grid
has an upper limit SNR=20 (400 counts) -- single pixel cells that
could not be subdivided further can exceed this limit.
</p>
<p>
The image on the Right shows the data with that binning applied. The
boundary of the cluster emission is more easily identified.
</p>
[binning.dmradar]
title : Adaptive Binning (Polar Coordinates)
requires: 6934_s3.fits
provides: 6934_rbin.fits 6934_rmask.fits
commands : dmradar 6934_s3.fits 6934_rbin.fits snr=20 xcenter=4033.7 ycenter=3956.8 method=0 shape=pie rinner=5 router=500 outmaskfile=6934_rmask.fits clob+
outfile : 6934_rmask.fits 6934_rbin.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -cmap load $ASCDS_CONTRIB/data/16_ramps.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
<tt>dmradar</tt> is the polar equivalent of <tt>dmnautilus</tt>.
Rather than subdivide the image in X and Y, <tt>dmradar</tt> divides
the image in Radius and Angle. This can provide a more natural
binning for circular or elliptically shaped emission.
</p>
posttext : <p>
The image on the Left shows the grid that <tt>dmradar</tt> computed, the
<tt>6934_rmask.fits</tt> output file. Each of the pie wedged in the grid
has an upper limit SNR=20 (400 counts).
</p>
<p>
The image on the Right shows the data with that binning applied. The
boundary of the cluster emission is more easily identified.
</p>
[binning.dmmaskbin.contour]
title : Contour Map Based Binning
requires: 6934_s3.fits 6934_s3.contour.map
provides: 6934_cbin.fits
commands : dmmaskbin 6934_s3.fits 6934_s3.contour.map 6934_cbin.fits clob+
outfile : 6934_s3.contour.map 6934_cbin.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -scale linear -cmap load $ASCDS_CONTRIB/data/16_ramps.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>
The <cxclink href="#binning.dmnautilus">dmnautilus example above</cxclink> shows
one example of an irregular, adaptive binning algorithm. There
are several other commonly used adaptive binning algorithms
in the community:
<extlink href="http://adsabs.harvard.edu/abs/2006MNRAS.368..497D">Weighted Voronoi
Tessellation</extlink> and
<extlink href="http://adsabs.harvard.edu/abs/2006MNRAS.371..829S">Contour Binning
</extlink>
are probably the most common two.
</p>
<p>
In this example we introduce the <tt>dmmaskbin</tt> tool that takes as input
a traditional counts (or flux) image along with a pixel-map image
(which pixels belong to which group) and uses those to create the
binned image.
</p>
posttext: <p>
In this example we have a input map (Left), <tt>6934_s3.contour.map</tt> .
The pixel value indicates to which group the pixel location belongs.
</p>
<p>
Right: The output image, <tt>6934_cbin.fits</tt> with a contour mapping binning applied.
The sum of the pixel values in each group from the input counts image
have been normalized by the size of the group and
that average value replicated in each pixel in the group in the output image.
</p>
[binning.dmmaskbin.hardness]
title : Map Based Binning: Hardness Ratio Map
requires: acisf00214N003_evt2.fits acisf00214_000N003_fov1.fits
provides: cas_a.fits cas_a_bin.fits cas_a_broad.map soft.fits hard.fits hardness.map
commands :
dmcopy "acisf00214N003_evt2.fits[sky=region(acisf00214_000N003_fov1.fits[ccd_id=7]),energy=500:7000]" cas_a.fits clob+
dmnautilus "cas_a.fits[bin sky=2]" cas_a_bin.fits snr=20 outmask=cas_a_broad.map clob+
dmmaskbin "cas_a.fits[energy=500:1500][bin sky=2]" cas_a_broad.map soft.fits clob+
dmmaskbin "cas_a.fits[energy=1500:7000][bin sky=2]" cas_a_broad.map hard.fits clob+
dmimgcalc soft.fits,hard.fits none hardness.map op="imgout=((img2-img1)/(img2+img1))" clob+
outfile : hardness.map
ds9_extras : -geometry %(geom_sqr)s -zoom 1 -cmap load $ASCDS_CONTRIB/data/004-phase.lut -cmap invert yes -scale limits -1 1 -view colorbar yes
pretext : <p>
Based on the <cxclink href="#binning.dmnautilus">above</cxclink>
<cxclink href="#binning.dmmaskbin.hex">two</cxclink>
examples we can now create a more useful example: Creating a map of the
hardness ratio. For simplicity we define the hardness ratio, <em>R</em>, as
</p>
<math>
<latex> \mathcal{R} = \frac{H-S}{H+S}</latex>
<name>hardness ratio</name>
<text> R = (H-S)/(H+S)</text>
</math>
<p>Where <tt>H</tt> is the number of counts in the hard (high) energy band
and <tt>S</tt> is the number of counts in the soft (low) energy band.
So a hardness ratio approaching 1.0 is a region dominated by
hard X-ray emission, and values approaching -1.0 are dominated by
soft emission.
</p>
posttext : <p>
In this example we take the event file for CasA and apply the spatial
binning and energy filtering we saw in the earlier examples.
</p>
<p>
We then run <tt>dmnautilus</tt> on the <em>broad</em> band, ie
combine hard+soft bands, to create a grid where we have
a combined SNR limit of 20 (ie a limit of 400 counts).
</p>
<p>
We then use this map to create an image of the soft band
and hard band counts.
</p>
<p>
And the finally we combine those two images using the equation
above to compute the hardness ratio map.
</p>
<p>
Since we have selected the bins to include roughly 400 counts each,
the statistical error in this map is low.
</p>
<p>
We can clearly see from this map the hard emission in the Western
part of the remnant. (North is towards the top of the image).
</p>
[binning.arbitrary]
title: Binning Arbitrary Axes
requires: cas_a.fits cas_a_broad.map
provides: cas_a.mapped.evt cas_a.spectra.img
commands:
dmimgpick cas_a.fits cas_a_broad.map cas_a.mapped.evt method=closest clob+
dmcopy "cas_a.mapped.evt[bin cas_a_broad_map=1:4957:1,pi=1:1024:1]" cas_a.spectra.img clob+
outfile: cas_a.spectra.img
ds9_extras: -geometry %(geom_sqr)s -pan to 2200 230 physical -scale log -cmap b
pretext:
<p>
So far all the binning example have been of data in sky coordinates.
However, we can bin data on any column in the input table.
</p>
<p>
In this example we will show a quick way to generate thousands of spectra
using the data <cxclink href="#binning.dmmaskbin.hardness">from
the hardness ratio example</cxclink>.
</p>
posttext:
<p>
This thread starts by using <tt>dmimgpick</tt> to add a new
column to the event file. The new column is called <tt>cas_a_broad_map</tt>.
The tool looks up the sky position for each event and then
uses the <tt>closest</tt> value in the map file to
populate the new column.
</p>
<p>
Next we use <tt>dmcopy</tt> to create an image but not in
sky coordinates. In this example the X-axis is the value of
the <tt>cas_a_broad_map</tt> column; ie the group ID.
The Y-axis is binned on <tt>pi</tt>, which is the
observed energy channel.
</p>
<p>
The results: We now have an image where each column is
the spectrum for different parts of the sky. The image
above shows just a small segment of the total image zoomed
into a region where we can clearly see the change in the
spectral signature.
</p>
<p>
Note: This type of spectrum is not immediately useful with CIAO,
as we do not have the appropriate response files (ARF and RMF),
nor do we have the information we need to account for background
(including area scaling information).
</p>
[binning.hexgrid]
title : Alternative binning: hexagonal grid
requires : 6934_s3.fits
provides :
commands : hexgrid "6934_s3.fits[sky=region(s3.fov)][opt full]" hex.map clob+ sidelen=10
map2reg hex.map hex.reg clob+
dmmaskbin 6934_s3.fits hex.map"[opt type=i4]" 6934_s3.hex10.fits clob+
outfile : hex.map 6934_s3.hex10.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region hex.reg
pretext : <p>
Typically we bin images into square (or more rarely rectangular) pixels
which approximates the physical geometry of the detector elements (ie
physical pixels on a CCD). The hexgrid tool allows users to create a
hexagonal grid to bin the data. Why hexagonal? It turns out that a
hexagon is the highest order regular polygon (equal length sides) that
can be used to uniformly tile a 2D plane. As such, it's the closest
approximation to a circle; and since the PSF is generally circular
(or at least elliptical), it may be a closer match to observed
sources.
</p>
<p>
The hexgrid tool creates a grid of hexagons, with equal side lengths.
The output map file is an image whose pixel values identify with
hexagonal group each (square) pixel belongs to.
</p>
posttext : <p>
In this example we created a hexagonal grid where each hexagon
is has a side length equal to 10 pixels. The input image was
filtered with the field-of-view file so that the tool knows where
the edge of the detector is and leaves those pixels ungrouped
(map value equal to 0). The map file is shown in the left-hand
side of the image. For the color map we have chosen a random
set of colors to help highlight the different map ID values.
</p>
<p>
The output map output is then run through the map2reg script to
create a region file from the map grid; one region is created for
each map ID value found in the input map file. Note: since
the map ID values are not necessarily continous nor do they
necessarily start at 1, the row number (not component value)
in the region file may not correspond to the map ID value in
the input file. This file can be used to easily display the map
grid as is shown in the right-hand side image.
</p>
<p>
As is shown in other Gallery examples, the dmmaskbin tool is then used
to apply the map file (unfortunately the terms "mask" and "map" are
sometimes used interchangeably) to the original counts image which
is what is display in the right-hand side image.
</p>
[binning.vtbin]
title : Alternative binning: Voronoi tessellation
requires : 6934_s3.fits
provides :
commands : aconvolve 6934_s3.fits 6934_s3_sm.fits "lib:gaus(2,5,1,3,3)" method=slide edge=const const=0 clob+
vtbin 6934_s3_sm.fits"[sky=region(s3.fov)][opt full]" vt.map clob+
map2reg vt.map vt.reg clob+
dmmaskbin 6934_s3.fits vt.map"[opt type=i4]" 6934_s3.vt.fits clob+
outfile : vt.map 6934_s3.vt.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region vt.reg
pretext : <p>
Another alternative binning technique is to create a grid based on
a <extlink href="https://en.wikipedia.org/wiki/Voronoi_diagram">Voronoi Tessellation</extlink>
of points. The key feature of the Voronoi tessellation is that each cell
is a convex hull that encloses each point. By default, the
vtbin tool selects the set of points that represents the local maxia
in the image. Since we are working with low count data, we want to
avoid many spurious "1 count" kind of local maxima caused by
random fluctuation so this technique works best when the image is
smoothed.
</p>
posttext : <p>In the left hand frame we see the map created by vtbin.
As with the hexgrid example, the pixel values represent the map ID
for each region; the color map is a set of random colors to show the
different regions. The right hand frame shows the output image
after the map file has been applied to the original input image
using the dmmaskbin tool with the region file created by map2reg
overlaid.
</p>
<p>
The choice of the initial central points is the key to this
algorithm. The default is to use the local maxima however
users can supply their own set of points which is used by the
<tt>centroid_map</tt> script.
</p>
[binning.centroid_map]
title : Alternative binning: centroid map
requires : 6934_s3.fits
provides :
commands : aconvolve 6934_s3.fits 6934_s3_sm.fits "lib:gaus(2,5,1,3,3)" method=slide edge=const const=0 clob+
centroid_map 6934_s3_sm.fits"[sky=region(s3.fov)][opt full]" centroid.map numiter=10 clob+
map2reg centroid.map centroid.reg clob+
dmmaskbin 6934_s3.fits centroid.map"[opt type=i4]" 6934_s3.centroid.fits clob+
outfile : centroid.map 6934_s3.centroid.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region centroid.reg
pretext : <p>
The <tt>vtbin</tt> output can contain highly irregular shapes,
though adhering to the condition that each is a convex polygon.
The <tt>centroid_map</tt> script takes this a step further. It runs
<tt>vtbin</tt> to generate an initial set of polygon regions. It
then computes the centroid of the events in each polygon and then
uses those centroids as input to <tt>vtbin</tt> to compute a new
set of polygon regions. This process is repeated a specified number
of time. [Theoretically this algorithm would converge so that the
centroids would not shift between iterations, but it does so somewhat
slowly especially at the edges of the data.]
</p>
<p>
The end result is that the output map file generally has much
more uniform, generally hexagonal shapes.
</p>
posttext : <p>
This is similar to the <tt>vtbin</tt> example showing the map file
on the left and the binned image on the right. The polygons are now
more uniform in size and spacing. For very bright sources, the
polgyons can become very small; users can use the <tt>scale</tt>
parameter to select different pixel scaling when computing the
centroid which will lessen the impact of bright pixels.
</p>
[binning.pathfinder]
title : Alternative binning: steepest ascent with pathfinder
requires : acisf04396_broad_thresh.img
provides :
commands : aconvolve "acisf04396_broad_thresh.img[bin sky=2]" orion.img "lib:gaus(2,5,5,2,2)" clob+
pathfinder orion.img pathfinder.map minval=1.0 clob+
map2reg pathfinder.map pathfinder.reg clob+
dmmaskbin orion.img pathfinder.map"[opt type=i4]" orion.pf.fits clob+
outfile : pathfinder.map orion.pf.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region pathfinder.reg
pretext : <p>
The <tt>dmimgblob</tt> tool creates a map file by identifying
clusters of connected pixels that share a side and assigning
each separate cluster to a separate group. The <tt>pathfinder</tt>
tool is somewhat similar but instead of grouping all pixels together it creates
groups by following the steepest gradient from one pixel to its
neighbors until it finds a local maxima. All pixels whose
steepest ascent gradient that reach the same maxima are grouped
together. This has the advantage that it can separate nearby point
sources. This tool is better suited for grouping images with
many point (or point-like) sources. It also works best when
the input image is smoothed so that it can find the steepest
gradient without needing to worry about statistical noise.
</p>
posttext : <p>
In this example of the star forming region in Orion, there are many
individual point sources and with diffuse emission in the center.
The algorithm is able to separate many of the individual stars based
on the gradient searching algorithm. The left image shows the map file
with a random color map applied. The right image shows the output
by binning the original image with the map file.
</p>
<p>
The amount of smoothing can have significant impact on the algorithm.
Using an adaptive smoothing tool like <tt>dmimgadapt</tt> or <tt>csmooth</tt>
may help to provide even better source separation. Subtracting the background
may also help to resolve all the point sources embedded in the
extended emission.
</p>
[binning.mkregmap]
title : Alternative binning: stack of regions with mkregmap
requires : 6934_s3.fits
provides :
commands :
dmellipse 6934_s3.fits ell.fits frac="lgrid(0.1:0.96:0.05)" step=100 clob+
mkregmap 6934_s3_sm.fits ell.fits"[#row=igrid(1:18:1)]" region.map clob+
dmmaskbin 6934_s3.fits region.map"[opt type=i4]" 6934_s3.region.fits clob+
outfile : region.map 6934_s3.region.fits
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region ell.fits
pretext : <p>
Another way to group data is with a <ahelp name="stack"/> of regions;
that is use a set of arbitrary regions to define each of the map IDs.
The regions can be uniformly created using the <tt>pgrid()</tt> or
<tt>rgrid()</tt> stack syntax, an arbitray list of regions provided
using the <tt>@filename</tt> syntax, or as shown in this example a
set of automatically created contour regions created by the
<tt>dmellipse</tt> tool.
</p>
<p>
In this example we create a set of elliptical contours that
enclose 5%%, 10%%, 15%%, ... up to 95%% of the total counts
in the image. We then create a map file using the <tt>mkregmap</tt>
script. The stack of regions is specified using the
<tt>igrid()</tt> syntax.
</p>
posttext : <p>
The map file (left image) created from the <tt>mkregmap</tt> script
shown with random colors. The right image shows the map file applied
to the original image. Since the region files are actually input
to the script there is not need to use <tt>map2reg</tt> to create them;
we can just directly overlay the contours on the binned image.
</p>
<p>
Question: How did we select the number "18" in the <tt>igrid(1:18:1)</tt>
syntax? Answer:
</p>
<screen>
unix%% dmlist ell.fits counts
18
</screen>
#~ [binning.merge_too_small]
#~ title : Alternative binning : merge small regions
#~ requires : 6934_s3.fits
#~ provides :
#~ commands : hexgrid "6934_s3.fits[sky=region(s3.fov)][opt full]" hex.map clob+ sidelen=10
#~ merge_too_small hex.map hex_min50cts.map imgfile=6934_s3.fits method=counts minval=50 clob+
#~ map2reg hex_min50cts.map hex_min50cts.reg clob+
#~ dmmaskbin 6934_s3.fits hex_min50cts.map"[opt type=i4]" 6934_s3.hex_min50cts10.fits clob+
#~ outfile : hex_min50cts.map 6934_s3.hex_min50cts10.fits
#~ ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/005-random.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -region hex_min50cts.reg
#~ pretext : <p>
#~ </p>
#~ posttext : <p>
#~ </p>
[smooth.aconvolve.gaus]
title : Smooth Image with Gaussian using FFT
requires : 635.img
provides: 635_gsm.img
commands : aconvolve %(requires)s %(provides)s kernelspec='lib:gaus(2,5,1,3,3)' clobber=yes
outfile : %(provides)s
ds9_extras : -scale log -geometry %(geom_sqr)s -zoom 0.6
pretext : <p>We start by simply convolving the input image with a circular, 2D Gaussian</p>
posttext : <p>
The syntax for the <tt>aconvovle kernelspec</tt> parameter has four parts.
The <tt>lib</tt> indicates that the smoothing kernel is to be constructed from
one of the built in library functions. The <tt>gaus</tt> indicates
the function to use: a Gaussian. The values in parentheses are the
parameters for the Gaussian. It is a <strong>2</strong>D Gaussian.
The kernel should extend out to <strong>5</strong> sigma in each
direction. The normalization is <strong>1</strong> (arbitrary here as the
default is to recompute a normalization so that the volume under
the kernel is 1). The final two parameter are the Gaussian sigma terms
for the X and Y axes. This example does not include the optional fourth
part of the kernelspec -- the location of the center of the smoothing
kernel.
</p>
<p>
Based on this description, we see that this specifies that the
data be smoothed by a 2D Gaussian with sigma=3.0 in both X and Y (ie,
circularly symmetric) out to a radius of 5*sigma
</p>
[smooth.aconvolve.box]
title : Smooth with rectangular box with sliding cell
requires: cas_a.spectra.img
provides: cas_a.spectra.sm_img
commands : aconvolve %(requires)s %(provides)s kernelspec="lib:box(2,1,1,10)" method=slide edge=const clob+
outfile : %(provides)s
ds9_extras : -geometry %(geom_sqr)s -pan to 2200 230 physical -scale log -cmap sls
pretext : <p>
The <tt>aconvolve</tt> tool allows for smoothing kernels of arbitrary
size. It also is not restricted to just smoothing images of the sky.
</p>
posttext : <p>
In this example, we take the image created in the
<cxclink href="binning.html#binning.arbitrary">Arbitrary Binning</cxclink>
example where the X-axis is the region ID number and the Y-axis
is the Energy. That image is smoothed with a 2D rectangular box that
is only 1 pixel wide (X-axis) but 10 pixels long (Y-axis).
</p>
[smooth.aconvolve.txt]
title : Smooth with Arbitrary Text Kernel
requires : 635_gaus.img
provides : 635_text.img
commands : aconvolve %(requires)s %(provides)s kernelspec="txt:((-1,-1,-1),(-1,8,-1),(-1,-1,-1))" method=slide norm=none edge=const clob+
outfile : %(provides)s
ds9_extras : -geometry %(geom_sqr)s -zoom 0.6 -scale limits -5 5 -cmap load $ASCDS_CONTRIB/data/heart.lut
pretext : <p>Sometimes it is useful to convolve with a simple, short array of numbers.
For example a Laplace edge detector is given by a 3x3 matrix.</p>
posttext : <p>
In this example a version of the Laplace edge detection kernel is used by
specifying a set of kernel values using the text, <tt>txt</tt> token.
The values are given in nested parentheses, going from left-to-right, the values represent the
bottom left pixel (first value), bottom middle pixel (2nd value), through the
upper right pixel (9th value).
</p>
<p>
Unlike the previous examples we also have set the normalization parameter
<tt>norm=none</tt>. This is because the sum of the pixels in the
kernel is 0; so leaving the normalization at its default value would
results in pixel values set to <tt>NaN</tt>.
</p>
[smooth.aconvolve.file]
title : Smooth with Image File
requires: 15403.img
provides: 15403.psf 15403_file.img
commands: arfcorr infile=%(requires)s outfile=15403.psf region='circle(32814.5,32638.5,100)' x=32814.5 y=32638.5 energy=1.0 mode=h clob+
aconvolve %(requires)s 15403_file.img kernelspec="file:15403.psf" clob+
outfile : %(requires)s %(provides)s
ds9_extras : -geometry %(geom_wide)s -tile mode column -frame 1 -zoom 2 -scale log -cmap bb -frame 2 -zoom 2 -scale log -cmap bb -frame 3 -zoom 2 -scale log -cmap bb
pretext: <p>The <tt>aconvolve</tt> tool can also convolve two images together
using the <tt>kernelspec=file</tt> option.
</p>
posttext: <p>
In this example we use the <tt>arfcorr</tt> tool to create a quick,
low fidelity, estimate of the Chandra PSF. The resulting image is
saved in the file <tt>15403.psf</tt>. This PSF is shown in the center
frame.
</p>
<p>
We then use that image with <tt>aconvolve</tt> as the convolution kernel.
The input image (shown on the left) is convolved with the PSF (center)
to produce the output on the right.
</p>
<p>
Note: the input image and the PSF do not need to be the same
size (MxN number of pixels); the PSF image can be smaller than the
input image. However, the images must have the same resolution (pixel size)
and tangent point.
</p>
[smooth.aconvolve.3d]
title : Smoothing 3D Image
requires: 06540_evt.fits
provides: cube.fits smcube.fits
commands : dmcopy "%(requires)s[(chipx,chipy)=box(8003.5,8137.5,512,512,0)][bin chipx=::2,chipy=::2,time=::#50]" outfile=cube.fits clob+
aconvolve cube.fits smcube.fits "txt:(((8)),((4)),((2)),((1)))" pad+ clob+
outfile : -3d smcube.fits
ds9_extras : -zoom 1.5 -geometry 500x800 -scale log -view buttons yes -view info yes -3d az 60 -3d el 30 -frame delete 1 -sleep 5
pretext : <p><tt>aconvolve</tt> supports multi-dimension images. This example shows a
3D image (cube) of a point source
shown in chip coordinates. Since Chandra dithers during the observation,
the point source
moves across the detector versus time, which is the 3rd dimension.</p>
posttext : <p>
The first step is to create the input data cube. Here an HRC event file is
filtered on the <tt>chip</tt> coordinates and then binned into a cube.
The X and Y axes are the chipx and chipy values binned by 2, and
the third axis is time binned into 50 bins.
</p>
<p>
This cube is input into <tt>aconvolve</tt>.
The convolution kernel used here acts like a delta function in the X and Y directions, and has
an exponential decay along the Z (3rd/time) axis.
The Lissajous pattern can be seen as the source dithers across the
detector.
</p>
[smooth.csmooth]
title : Adaptive Smoothing with csmooth
requires: 635.img
provides: 635.img 635_csm.img 635_sig.img 635_scl.img
commands : csmooth infile=%(requires)s outfile=635_csm.img outsig=635_sig.img outscl=635_scl.img sigmin=3 sigmax=5 sclmax=45 clob+ mode=hl
outfile : 635_csm.img
ds9_extras : -geometry %(geom_sqr)s -zoom 0.6 -scale log -scale limits 0 500 -cmap load $ASCDS_CONTRIB/data/purple4.lut
pretext : <p>
<tt>aconvolve</tt> does a linear smoothing. It smooths each pixel in the
input with the same smoothing kernel. This works very well when
all the interesting features in the input are approximately the same
size and amplitude. However, when there are different size features
(eg sources) with different amplitudes, a single linear convolution
may be inadequate.
</p>
<p>
There are various adaptive smoothing techniques. They differ in
performance; how smoothing scales are selected; figure of merit used
to know when data are sufficiently smoothed (ie number of counts); etc.
</p>
<p>
CIAO includes the <tt>csmooth</tt> tool. This is an
implementation of Harald Ebeling's
<extlink href="http://adsabs.harvard.edu/abs/2006MNRAS.368...65E">
<tt>asmooth</tt> algorithm</extlink>.
Using the default parameter settings, this algorithm
smooths the data until the signal-to-noise in each pixel is between
the input limits. It estimates the background from an annulus
around each pixel; the size is based on the size of the kernel radius.
</p>
posttext :
<p>
<tt>csmooth</tt> is fairly simple to run. It outputs the smoothed
image as well as images that record the smoothing scale and the significance
at each pixel location.
</p>
<p>
Users should be careful about how they use the output image. The
flux in the image is not preserved (a local background has been
subtracted.) There may also be some unphysical structure that
emerges if there is significant structure in the background.
</p>
[smooth.dmimgadapt.gaus]
title : Adaptive Smoothing with dmimgadapt
requires: 635.img
provides: 635_adapt.img
commands : dmimgadapt %(requires)s out=%(provides)s min=1 max=45 num=45 radscal=log fun=gaus counts=25 verb=3 clob+
outfile : %(provides)s
ds9_extras : -geometry %(geom_sqr)s -zoom 0.6 -scale log -scale limits 0 500 -cmap load $ASCDS_CONTRIB/data/purple4.lut
pretext : <p>
CIAO also provides the <ahelp name="dmimgadapt" tt="1"/> tools
which does preserve flux. However, it does not estimate nor use
a background in any way.
</p>
<p>
<tt>dmimgadapt</tt> may be a faster choice depending on the number of
scales used. It also provides more choices in convolution kernels
which can also greatly increase the speed.
</p>
posttext:
<p>
This <tt>dmimgadapt</tt> output is a direct comparison to the
<cxclink href="#smooth.csmooth"><tt>csmooth</tt></cxclink> example
above. Both use a Gaussian convolution kernel to get
approximately 5-sigma, ie 25 counts.
</p>
<p>
It's worth highlighting that the <tt>dmimgadapt</tt> tool knows about the
filters which have been applied to the input file (aka the file's
data-subspace). This is why the off-chip pixels appear white in
this image -- they are actually <tt>NaN</tt>, whereas <tt>csmooth</tt>
does not know about off-chip pixels, so the same area is filled with
the value 0 (shown as black).
</p>
[smooth.dmimgadapt.cone]
title : Adaptive smoothing with cone shaped kernel
requires: 635.img
provides: 635_adapt_cone.img
commands: dmimgadapt %(requires)s out=%(provides)s min=1 max=45 num=100 radscal=log fun=cone counts=16 verb=3 clob+
outfile : %(provides)s
ds9_extras : -geometry %(geom_sqr)s -zoom 0.6 -scale log -scale limits 0 500 -cmap load $ASCDS_CONTRIB/data/purple4.lut
pretext : <p>
While using a Gaussian is the most natural choice, it may not be the best
option to start with. By definition, a Gaussian has infinite support (is
non-zero everywhere). However, beyond some limit, the amplitude of the
Gaussian is negligible. Most algorithms make an arbitrary cutoff,
usually as a function of FWHM or sigma. Even so, the size of the
Gaussian kernel may be quite large; leading to longer program runtimes.
</p>
<p>
<tt>dmimgadapt</tt> has several other smoothing kernel options which
have finite support (identically 0 beyond some limit) and yet still
retain the general shape of a Gaussian. Choosing one of these kernels
can greatly reduce the program's runtime, which can be especially
useful when doing exploratory analysis trying to determine the range
of other input parameters to use.
</p>
posttext : <p>
This example shows <tt>dmimgadapt</tt> using the circular <tt>cone</tt>
shaped kernel. This example uses more smoothing kernels
than the <cxclink href="#smooth.dmimgadapt.gaus">previous example</cxclink>;
and yet because the cone is easier to compute and has a finite base, the
<tt>dmimgadapt</tt> program runs much faster.
</p>
<p>
Visually this image is nearly identical to the previous example.
Since selecting the set of smoothing kernel scales is often an
iterative task, we can use the <tt>cone</tt> kernel to
quickly optimize those parameters first and then run again
using <tt>gaus</tt> to produce the final product.
</p>
[smooth.dmimgadapt.tophat]
title : Circle With Minimum Number of Counts
requires: 214.img
provides: 214_adapt.img min_100cts.map
commands : dmimgadapt %(requires)s out=214_adapt.img min=1 max=20 num=20 radscal=linear fun=tophat counts=100 verb=3 radfile=min_100cts.map clob+
outfile : min_100cts.map
ds9_extras : -geometry %(geom_sqr)s -zoom 1 -linear -cmap load $ASCDS_CONTRIB/data/16_ramps.lut -view colorbar yes
pretext :
<p>
The primary output from <tt>dmimgadapt</tt> is usually the smoothed image. However, it
also provides a map with the size of the smoothing kernel radius
as well as the SNR and normalization.
</p>
<p>
The radius map can be very useful for various types of analysis. Consider the
case of doing spectral fitting where we require a minimum number of
counts to get reliable fit results. We may need to know the size
of a circle centered at each pixel location that encloses, for example, at least
100 counts. This is easy to get using <tt>dmimgadapt</tt>.
</p>
posttext : <p>The image shown is the <tt>min_100cts.map</tt> file.
Note that units of the radii are in logical pixels, so if an image is binned > 1, which is the
case here, you want to be sure to take that into account when using this file.
</p>
<p>
See also the <threadlink name="ttt_mincounts"/> thread.
</p>
[smooth.ggm]
title : Gaussian Gradient Magnitude
requires: abell496_broad_thresh.img
provides: abell496_gaus10.img abell496_ggm.img abell496_grad.img
commands : aconvolve abell496_broad_thresh.img abell496_gaus10.img "lib:gaus(2,5,5,10,10)" meth=fft clob+
aconvolve abell496_gaus10.img abell496_grad.img "txt:((0,1,0),(1,-4,1),(0,1,0))" metho=fft clob+ norm=none
dmimgcalc abell496_grad.img none abell496_ggm.img op="imgout=(abs(img1)*sqrt(2.0))" clob+
outfile : abell496_broad_thresh.img abell496_ggm.img
ds9_extras : -geometry %(geom_wide)s -frame 1 -scale log -pan to 4065 3890 physical -cmap load $ASCDS_CONTRIB/data/gem-256.lut -frame 2 -scale linear -pan to 4065 3890 physical -cmap load $ASCDS_CONTRIB/data/iman.lut -view colorbar on -colorbar vertical
pretext :
<p>
The <em>Gaussian Gradient Magnitude</em> algorithm
is <extlink href="http://adsabs.harvard.edu/abs/2016MNRAS.461..684W">becoming
increasingly popular in astronomy image processing</extlink>.
The derivative of a Gaussian is an effective edge detector
which suppresses high-spatial frequencies, most often associated
with the background.
</p>
<p>
We can make use of the convolution identity:
</p>
<math><name>gradient</name>
<latex> I \ast \nabla h = \nabla (I \ast h)</latex>
<text> I * dh = d(I*h)</text>
</math>
<p>
where <tt>I</tt> is the input image and <tt>h</tt> is a
Gaussian. This means that rather than trying to compute the
partial derivatives of a Gaussian; we only need to
convolve the image with a Gaussian, and then compute the
image gradient.
</p>
<p>
The gradient of an image can be estimated by convolving it
with a specially constructed convolution kernel; for example the
Laplace kernel = <tt>((0,1,0),(1,-4,1),(0,1,0))</tt>
</p>
<p>
As shown here, the <em>GGM</em> is then easy to compute
by running <tt>aconvolve</tt> twice.
<tt>dmimgcalc</tt> is then used to compute the <em>magnitude</em>
of the gradient estimator; which here is just the absolute value
of the gradient (the factor of sqrt(2.0) is included for completeness.)
</p>
posttext :
<p>
In this example we start by smoothing the image with a 10 pixel
Gaussian, and then estimating the gradient using the Laplace convolution
kernel. The result here shows a cavity North of the center of the cluster
which can then be further analyzed.
</p>
<p>
The choice of the smoothing scale affects the size of detectable features.
To look for large scale features, a large smoothing scale is required.
The scale should always be larger than the local PSF size. Since
the Chandra PSF varies, some researchers have found innovative ways
<extlink href="https://github.com/jeremysanders/ggm">to combine GGM
from several scales into a single product</extlink>.
</p>
[smooth.gradient]
title : Directional Gradient Estimators
requires: abell496_gaus10.img
provides: abell496_dx.img abell496_dy.img abell_sobel.mag abell_sobel.ang
commands : aconvolve %(requires)s abell496_dx.img "txt:((1,2,1),(0,0,0),(-1,-2,-1))" meth=fft clob+ norm=none
aconvolve %(requires)s abell496_dy.img "txt:((-1,0,1),(-2,0,2),(-1,0,1))" meth=fft clob+ norm=none
dmimgcalc abell496_dx.img,abell496_dy.img none abell_sobel.mag op="imgout=sqrt((img1*img1)+(img2*img2))" mode=h clob+
dmimgcalc abell496_dx.img,abell496_dy.img none abell_sobel.ang op="imgout=atan(img2/img1)" mode=h clob+
outfile : abell_sobel.mag abell_sobel.ang
ds9_extras : -geometry %(geom_wide)s -frame 1 -zoom 0.5 -scale log -cmap h5_bone -frame 2 -zoom 0.5
pretext : <p>In the <cxclink href="#smooth.ggm">previous example</cxclink>
we used the Laplacian gradient estimator. The nice thing about this
estimator is that it can be computed with a single convolution. However, it only contains
information about the magnitude of the
gradient, not the direction. To get directional information about the gradient,
we have to use other gradient estimators.
</p>
<p>
One of the most common gradient estimators is the Sobel kernel. There is a
separate convolution kernel designed to
estimate the gradient in the X-direction and in the Y-direction. These then
just need to be combined together to get the magnitude and the angle
of the gradient.
</p>
posttext : <p>
In this example we used <tt>aconvolve</tt> to compute the directional gradient in
the X-direction and separately in the Y-direction. Then <tt>dmimgcalc</tt> is used
to compute the magnitude (left) and angle (right) of the gradient. The data are the
same shown in <cxclink href="#smooth.ggm">the Gaussian Gradient Magnitude example
</cxclink>, but zoomed out by 50%%. The edge of the cluster emission is easy to identify in
the gradient magnitude image (left). The gradient direction image (right) is harder to
interpret since the angle wraps at 180 degrees, creating an artificial discontinuity.
</p>
<p>
Some other common gradient estimators include:
</p>
<table class="ciaotable">
<tr><th>Name</th><th>X</th><th>Y</th></tr>
<tr><td>Laplace</td><td><tt>((0,1,0),(1,-4,1),(0,1,0))</tt></td><td><tt>((0,1,0),(1,-4,1),(0,1,0))</tt></td></tr>
<tr><td>Sobel</td><td><tt>((1,2,1),(0,0,0),(-1,-2,-1))</tt></td><td><tt>((-1,0,1),(-2,0,2),(-1,0,1))</tt></td></tr>
<tr><td>Roberts</td><td><tt>((1,0),(0,-1))</tt></td><td><tt>((0,1),(-1,0))</tt></td></tr>
<tr><td>Prewitt</td><td><tt>((1,1,1),(0,0,0),(-1,-1,-1))</tt></td><td><tt>((-1,-1,-1),(0,0,0),(1,1,1))</tt></td></tr>
<tr><td>Robinson</td><td><tt>((1,1,1),(1,-2,1),(-1,-1,-1))</tt></td><td><tt>((-1,1,1),(-1,-2,1),(-1,1,1))</tt></td></tr>
<tr><td>Kirsch</td><td><tt>((3,3,3),(3,0,3),(-5,-5,-5))</tt></td><td><tt>((-5,3,3),(-5,0,3),(-5,3,3))</tt></td></tr>
</table>
[smooth.unsharp.mask]
title : Unsharp Mask
requires: abell2390.img
provides: abell2390_g3.img abell2390_g30.img abell2390_unsharpmask.img
commands : aconvolve %(requires)s abell2390_g3.img "lib:gaus(2,5,5,3,3)" meth=fft mode=h clob+
aconvolve %(requires)s abell2390_g30.img "lib:gaus(2,5,5,30,30)" meth=fft mode=h clob+
dmimgcalc abell2390_g3.img abell2390_g30.img abell2390_unsharpmask.img sub clob+
outfile : abell2390.img abell2390_unsharpmask.img
ds9_extras : -geometry %(geom_wide)s -frame 1 -scale log -cmap load $ASCDS_CONTRIB/data/brain.lut -frame 2 -scale log -cmap load $ASCDS_CONTRIB/data/heart.lut -view colorbar on
pretext :
<p>
Unsharp masks have been used by photographers for decades to
improve the contrast of photographs. This technique involves
slightly blurring the original image, inverting it, and adding a
scaled version of the inverted, blurred image back to the original image. The result is
that edges become more pronounced and visually appealing.
</p>
<p>
Mathematically this looks like:
</p>
<math>
<name>Unsharp</name>
<latex> U = I - I\ast h</latex>
<text></text>
</math>
<p>
Where I is the original image, h is the smoothing function (usually a Gaussian),
and U is the unsharp mask. Since a Gaussian is a low pass filter
(it tends to preserve large spatial features), by subtracting
the smoothed image from itself we are then accentuating small
scale features such as edges or boundaries between objects (ie