Subject: Re: New IMOD group Hi Peter, In principle I like your idea of packing the information in well designed C-structs. The pixel remapping, however, is not suited for this, in my opinion, unless the data are read into fixed-size arrays i.e. list_idx[65536][11], and fraction[65536][11]. Am I old-fashioned if I consider these to be a heavy load to carry around? Apart from that I will try to see where the struct elements could be useful in my part of the ISSW: JEMXdetectorData shadowgram basic_recon src_find cor_intensity area - + + + detMap - + 1) + + CorX/Y - 2) - - - pixelArea - 2) - - - pixelLowerLeftX/Y - 2) - - - 1) If the event selection 'rowSelect' used in j_ima_shadowgram is handed over to all later components e.g. by FITS keyword then, in principle, it should be possible to calculate vignetting 2) Assuming that the regularized shadowgram is the starting point From this rather superficial analysis I'd say that the struct should be shrunk. It might be useful if you all made similar analyses. Regards Niels Joergen ---------- Niels J. Westergaard Danish Space Research Institute Juliane Maries Vej 30, DK 2100 Copenhagen O Phone: +45 35 32 57 05; FAX: +45 35 36 24 75 X-Original-To: oxborrow@dsri.dk Delivered-To: oxborrow@dsri.dk Date: Thu, 2 Sep 2004 16:40:20 +0200 (MEST) From: Niels Joergen Westergaard To: Active SDAST -- Carol Anne Oxborrow , Jérôme Chenevez , "Niels J. Westergaard" , Niels Lund , Paul Connell , Peter Kretschmar , Sami Maisala , Silvia Martínez Núñez , Soren Brandt , Stefan Larsson Subject: C struct again MIME-Version: 1.0 Hi, I forgot to mention that I strongly prefer what Peter calls 'linear mapping' i.e. using arr[y*xsize + x] in stead of arr[x][y] For the latter it implies that y is the most rapidly changing index which is not the case in FITS representation. I like to be in control of that. On long names: I agree with Peter that names should be as long as needed so we don't have to bother with abbreviations that we have (read: I have) a tendency to forget the meaning of - on the other hand I think that Peter's proposal is too far in the opposite direction. (JEMXdetectorGetRegularizedPixelMapping) Regards Niels Joergen X-Virus-Status: No, clean X-Paranoid-Status: No, hits=0 required=25.00 Date: Thu, 02 Sep 2004 17:43:32 +0200 From: Peter Kretschmar Subject: Re: New IMOD group To: Niels Joergen Westergaard Cc: allan@dsri.dk, silvia.martinez@uv.es, stefan@astro.su.se, juhani.huovelin@astro.helsinki.fi, smaisala@astro.helsinki.fi, oxborrow@dsri.dk, sb@dsri.dk, jerome@dsri.dk, nl@dsri.dk, Paul Connell MIME-version: 1.0 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Comment: This message was scanned against viruses by mbx.unige.ch. Thanks for the rapid response Niels Jørgen, > The pixel remapping, however, is not suited for this, in my opinion, > unless the data are read into fixed-size arrays i.e. list_idx[65536][11], > and fraction[65536][11]. Am I old-fashioned if I consider these to be a > heavy load to carry around? > Yes, you are :-) OK, this would give 65536*11*(4+4+4) bytes or maybe *(4+4+8) if we allow double fractions so <9 or <12 Mb. How about the 65536 (or more) file accesses you need (also in my proposal), have you tested that? > > 1) If the event selection 'rowSelect' used in j_ima_shadowgram is handed > over to all later components e.g. by FITS keyword then, in principle, it > should be possible to calculate vignetting > Good idea. Can long keywords be any length? Also, I still think that normal users should _not_ set rowSelect themselves but have clear parameters to set like "ignoreBadAnode", "ignoreHotSpot", ... The scripts could ensure to pass these parameters on to all relevant tools but actually it would be more elegant in your case to write this to the shadowgrams. > 2) Assuming that the regularized shadowgram is the starting point > Stefan and I use events directly - how does the regularized shadowgram help us? > > It might be useful if you all made similar analyses. > Indeed ... here's my attempt. Stefan? Niels? JEMXdetectorData bin_evts_[spectra+lc] area + detMap + CorX/Y + pixelArea - pixelLowerLeftX/Y - > I forgot to mention that I strongly prefer what Peter calls 'linear > mapping' i.e. using > arr[y*xsize + x] > in stead of arr[x][y] > > For the latter it implies that y is the most rapidly changing index which > is not the case in FITS representation. I like to be in control of that. > But the shared read functions could and should take care of that. I don't care too much as long as we have a common & comprehensible way of addressing our arrays. In my 2D proposal [x][y] always should match RAWX, RAWY. > On long names: I agree with Peter that names should be as long as needed > so we don't have to bother with abbreviations that we have (read: I have) > a tendency to forget the meaning of - on the other hand I think that > Peter's proposal is too far in the opposite direction. > (JEMXdetectorGetRegularizedPixelMapping) > I was a _bit_ provocative but with a decent editor it's not much trouble to have such names ... how about: JEMXdetGetRegularPixelMap() ? Cheers, Peter