Hello everybody. I’m new to ROOT and I have been doing some tests in order to see whether it is a suitable platform for developing astronomy software. I have navigated thru the Reference Guide and I’ve seen that there exists a enumeration constant TImage::kFits, which lead me to think that ROOT supports this kind of image. However I can’t find any library within the ROOT’s directory tree for accessing FITS files. Furthermore, TASImage is a layer for interfacing libAfterImage, which doesn’t support FITS (as far as I know). My question is: should I create a layer for accessing FITS using for example the publicly available cfitsio library? Will ever ROOT come with FITS support by means of a plugin like TASImage? I’ve read some messages in the digest referring to FITS but they are quite old. Does anybody know some kind of plugin for supporting FITS (before I make my own)? I know there exists AstroROOT, however I think there are some incompatibilities with Microsoft Windows, and I need cross compatibility with Windows, MAC OS X and Linux. Maybe I could just “steal” the source code related with FITS from AstroROOT.
Your analysis is correct. We will be happy to include interfaces to FITS from TASImage if you provide one.
Currently TASIMage is interfaced with libAfterImage only, but we could support multiple interfaces.
Thank you for your reply. Actually, FITS is much more than an image file. Since it may contain images with up to 64 bits/channel, the interface should compress the range down to 8 bits/channel. Furthermore, image channels within a FITS file can be application dependant (not necessarily color channels). On the other hand FITS files may also contain data tables, whose information could be related with images in the file. Actually, as far as I’ve learned on ROOT, FITS files share with ROOT files the goal to store information of several kinds, even information for describing other information within the file. Therefore, I will make a simple interface that just loads a grayscale image from a FITS file, which is the most likely case in astronomy ccd pictures [my goal]. Actually, somebody wanting to exploit a FITS file 100% will need, not an image interface layer as TASImage, but a more extended plugin (which I probably implement much later).
I’ll try to look for information for creating/modifying plugins.
Hi again.
I finally could make TASImage to open FITS files (write support is still pending). Actually I’ve implemented TASPluginFITS, which looks for the first image available within a FITS file and opens it. The plugin only supports monochrome images since FITS specification does not say anything about color images: images within a FITS files are just bidimensional arrays of values which should be combined by the user appropriately however he wants, in order to generate, for example, an RGB composition.
On the other hand FITS does require a better interface than TImage because, as I said in previous posts, FITS may contain not one, but several images and also data tables. Actually the following data can be found within a FITS file:
Due to the level of complexity that can be achieved within a FITS file, some kind of special interface should be implemented. For example, let “fits” be an object of a class called “TFits” that handles a FITS file. It should be interesting to do: fits->CombineToRGB(“halpha”, “oIII”, “SII”), which would create a TImage object representing a pseudo-color image with R = intensity on Hydrogen-alfa , G=Oxygen-3, B=Sulphur-2, bands, which are described within the FITS file.
Could somebody give me some ideas of where should I create such interface within the root’s source code directory tree?
Finally, I add below the steps I followed to create the TASPluginFITS plugin (please, correct me if I missed something):
Created folder called “libcfitsio” in graf2d/src containing a snapshot of CFITSIO source code
Created file “TASPluginFITS.cxx” in graf2d/src
Created file “TASPluginFITS.h” in graf2d/inc
Updated file asimage/Module.mk to configure and make libcfitsio and plugin
Created file etc/plugins/TImagePlugin/P010_TASPluginFITS.C
As FITS as more functionality than TImage a class TFITS might be the solution.
It can may be go in graf2d/asimage.
I guess extending TImage to match FITS functionality is unrealistic… right ?
what about separating the image handling (which could be done by TASImage as you suggested) and the file management? Can you create a TFITS class which allows to extract and combine images as TImage objects (via your TASPluginFITS) as well as data tables as some sort of ROOT objects as you find appropriate, e.g. TGraph? For this class you don’t have to find a proper location - we’ll do that later.
Fons will contact the AstroROOT people to see whether they have an opinion.
Yes, sure! For example, a FITS file can contain a picture of the Orion nebula in R,G,B and
also in other bands like H-alpha and O-3. FITS actually doesn’t fit in the image concept
Yes, I was exactly thinking like you. However I’m still digging in ROOT’s features (I started using it 3 days ago) and I have not evaluated all possible interfaces yet.
Great. I already was about to contact them. Actually it was a surprise for me that their work were not
included in the ROOT’s code mainstream. I’m not planning to use AstroROOT to avoid keeping track of 2 platforms: ROOT and AstroROOT. It would be great that ROOT expanded as new needs appear.
Just a final comment: I’m baffled by ROOT’s capabilities. I think it could become a free and more powerful platform than MATLAB (of course, several times faster).
ROOT is great. Sorry, but somebody should have said it!
The TFITS class will read FITS files and transform them into TImage (or even may be TH2 ?).
Do you also plan to be able to write such files ?
I was reading: en.wikipedia.org/wiki/FITS
1st of all I was a bit surprised that it was released first in 1981 !
According to this description, it should ne be too difficult to write such files also… I might be wrong of course.
as you can see: isdc.unige.ch/astroroot/highlights AstroROOT covers many of the issues you try to address (and more). Of course we could have included all AstroROOT code into the ROOT svn, while that has advantages, e.g. easily available, tested with the trunk, etc. it also has disadvantages, e.g. difficult to support different versions of AstroROOT with different versions of ROOT, independent release schedules, etc. Especially since the core ROOT HEP user community and the Astro community don’t overlap that much. Anyway, till now this worked pretty well and there are quite some other ROOT add-on systems that are maintained outside of the ROOT code tree. It should be entirely possible to build the AstroROOT libraries and use them directly from ROOT (i.e. they are not two systems). In case AstroROOT is not covering Windows and MacOS X then we should make an effort to fix that as it cannot be that difficult.
I am using astroroot on everyday basis. So far I only once had a compatibility issue when I could not easly recompile astroroot with a new ROOT release, but it was a very long time ago. Since than, I had no problems making apps taking advantage of astroroot and root in the same time. However, that is only on linux.
Yes, the same I thought the first time I dealt with this file format…I was born in that year too!
You have nailed it! On one side of the scales there is AstroROOT’s powerful FITS managing features. On the other side, the fact of moving AstroROOT to successive versions of ROOT.
Actually in the AstroROOT’s download page it says: “AstroROOT Version 5.0 is tested with ROOT version 5.08.00 and 5.18.00. Unfortunately it does not compile with ROOT version 5.16.00.”.
I don’t know whether it compiles with v5.26.00 (which I have installed), so I should give a try.
I’m gonna think what to do. Maybe I will try to follow ROOT’s development guidelines to create a clean interface for FITS files based on AstroROOT’s source.
As I said above, I have to check whether compilation is successful with v5.26.00. Regarding OS compatibility, I have no problems using Linux (actually I mainly use it) but I worry about end application users, which most of them use MS Windows. A good example of application based on ROOT is “Astrometrica” (astrometrica.at/)
which runs on Windows.
FITS is a file format. TImage is a class to display data. These are different subjects, which should not be mixed up. If ROOT wants to support FITS you just must be able to create, read and write FITS files, with their so called extensions. An extension is either a n-dimensional image array or a table with columns and rows. The question now is: into which data structure / class you want to read the data from a FITS image / table? You can think of a TFits class. My proposal would be to add a method to TTree to read and write FITS tables and to add a method to TH2x and TH3x to read and write FITS image arrays. I guess with these methods you have everything what you need. (You also can think of derived classes like class TFitsTable : public TTree and TFitsImage: public TH2x)
You may be surprised that I, as the author of AstroROOT, do not mention AstroROOT at all. Yes, today I would make a new design when I should implement a FITS interface in ROOT.
If someone makes a design, I would be happy to look to it carefully and send my comments. Unfortunately currently I do not have time to make it by myself or to implement anything.
thank you very much, Reiner, for offering to help us with your expertise and for your constructive and helpful comments!
Claudi, can you come up with a class which represents a FITS file as I suggested (read only, for now), and which allows to extract TImages and “data tables”. The modifications should be local to that class as much as possible; I hope we don’t need to change TTree etc! Once you have it I am sure Reiner and Olivier and I will have nasty comments If you’re not afraid of that we’d really appreciate seeing your proposal!
We can also take this off list - email is a better medium for discussing implementations. Send it to Olivier or me (axel@cern.ch) and we will add the others CC.
Reiner: nice to meet AstroROOT’s creator. Your idea of embedding FITS I/O within TTree looks great. However I’d rather do the second option you have proposed: adding derived classes to avoid specializing general purpose classes.
Haha…Sure I’m not. I think that was Einstein who once said that anyone who has never made a mistake, has never tried anything new. OK then, I will implement a class to extract information within FITS files. I’m also gonna move this discussion to email.
If you’re not afraid of that we’d really appreciate seeing your proposal!