Dal sito www.weasner.com ho estrapolato l'intervento di tale Niall J. Saunders che fornisce un'interessante panoramica dei diversi formati di salvataggio della Meade DSI illustrandone i vantaggi e gli svantaggi ai fini del post processing.

Gli ho anche scritto per chiedergli qualche ulteriore informazione.
Attendo risposta.

Di seguito il testo dell'intervento.

Un saluto

Sergio


__________________

Subject: Unable to change format of AutoStar files
Sent: Sunday, November 5, 2006 15:24:34
From: Niall J. Saunders (niall@njs101.com)
Assuming that you are running the latest version of Envisage (and you
should be if you're not !!), then you want to look for the button marked
[Save Proc ...] at the top right hand edge of the Envisage window. Make
sure that you can see ALL of the edges of the Envisage window,
especially if you are using a lower resolution screen (you really want
to be running at 1024 x 768, or higher, if at all possible).

Press the [Save Proc...] button, and a small window labelled should open. On that window there is a drop-down selector next
to the "File Type" label. Click the selector, and choose how you want to
save your images. It is easiest if you use your Up/Down cursor keys to
do this, as you will be able to read a short description next to each
possible choice.

The choices available are BMP, Gif, Jpeg, Png, TIF, Fits, Fits3P and
FitsInt

The comments given by Envisage are (verbatim) :-

BMP - Uncompressed, 24 Bit Color compatable with paint, IP, Photoshop
Gif - Lo res, 8 bit int, compatible with: web
Jpeg - Compressed, 24 Bit Color , compatible with: Photoshop, web
Png - Compressed, 24 Bit Color , compatible with: Photoshop, web
TIF - Uncompressed, 24 Bit Color , compatible with: Photoshop
Fits - Uncompressed, 3 file RGB, 32 bit float, compatible with IP, MaxIm
DL
Fits3P - Uncompressed, Single color file, 32 bit Float, compatible with
MaxIm DL V3.x
FitsInt - Uncompressed, 3 file RGB, 16 bit int, compatible with RegiStax

There is little advantage in using either Jpeg or Png formats as both of
these use LOSSY compression - which means that you are immediately going
to lose some of the data that you have worked so hard to obtain in the
first place (there are exceptions to this - but you will know yourself
when you are willing to forsake captured data quality in favour of
easier data manipulation at the post-processing stage).

The Gif format is even worse when trying to preserve the data that you
are capturing. All the other formats try to capture at least 24-bit
colour information. The Gif format only stores 8-bit information. Each
image will be reduced to the best palette of 256 colours that will 'fit'
the original 281,474,976,710,656 (almost 300 BILLION) colours that could
have been in the original (DSI) image - even the LPI could provide
almost 17 MILLION colours. Gif is most likely NOT going to be a format
that you will be using that often !!

The two 24 bit formats, BMP and TIF, seem to be more or less identical
in both resultant file size and quality of image recorded. There is one
VERY IMPORTANT consideration that you must keep in mind when using
either of these two formats. Because they are only recording 24-bit data
(8 bits, each, for Red, Green and Blue - RGB) they are NOT recording the
maximum possible dynamic range available from the DSI range of imagers.
(They ARE capable of capturing the normal dynamic range of the LPI,
however, as it is only an 8-bit imager, whereas the DSI is a 16-bit
device).

More importantly, the BMP and TIF image files that are saved to disc are
saved AFTER the raw data has been manipulated as a result of how you,
the user, have set the Histogram Slider Controls. In other words, as you
move the sliders around during an imaging sequence, any changes will be
recorded in the saved images. It is especially important that you are
aware of this if you are running in "Save all Uncombined Images" mode.

You should also be aware that your computer monitor itself is a
fundamental limit when it comes to 'looking' at the image - your screen
(LCD or CRT) can only (at best) display 24-bit (3x8-bit) RGB data.
Normally you will be moving the Histogram Sliders around to get a
'nice-looking' image on the screen. What you do not really want is to
have your 'live' interpretation of what 'looks nice' to have affected
the data that you might be storing for later post-processing. And it
will nearly always be in the 'post-processing' stage that you will be
able to extract the 'best' image from your 'raw data'.

That just leaves the three FITS methods. All of these will try to
preserve the FULL dynamic range available from the likes of the 16-bit
DSI cameras. (I am going to exclude the DSI-Pro and the DSI-II-Pro
cameras from detailed discussion here, because although I have just
taken delivery of a DSI-II-Pro as a birthday gift from my darling wife,
unless there is some sort of major heavenly display between now and the
end of November, it really ought to be staying wrapped up for my actual
birthday !! - I'll post details thereafter, once I have learned to play
with that little beastie !)

The simplest is the FitsInt mode, where a file of 16-bit data is saved
for each of the three colour planes (Red, Green and Blue, or RGB). A
fourth file is also saved for each image frame that you capture and
store. This is the LUMINANCE image (L), and is a plane, representing
brightness, that is 'synthesised' from the captured RGB data. In fact,
the actual process is somewhat more complex when you are working with
the DSI-C and DSI-IIC cameras - this is because the CCD chips that are
used are actually a form of CMY (Cyan, Magenta and Yellow) sensor - and
the Envisage software has to process the incoming RAW (CMY) data in
order to create the RGB format that most users want to see on their RGB
computer monitor.

The Fits mode (32-bit, three-file mode) is something that I have not
experimented with - simply because I have not been able to get to grips
with the extremely convoluted user interface that is Meade's Autostar IP
program, and because I cannot justify the ridiculously high price of
MaxIM DL (in any of its variants). That said, the Fits mode saves four
data files per image frame captured. What makes this mode the 'best' is
that the 32-bit 'float' format allows the data to be manipulated by
sophisticated software with less likelihood of data being lost due to
'truncating errors' that would appear if the data was in a format such
as 16-bit Integer (FitsInt) mode. This is not a major advantage at the
time of image capture however, as there are many methods of converting
what is, after all, 16-bit integer data in the first place, into the
32-bit 'real' or 'float' data that is being looked for by the likes of
Autostar IP and MaxIm DL.

The last method, Fits 3P, is one where two files are stored for each
image captured. One contains all three sets of 16-bit data for the three
colour (RGB) planes, and the second contains the (extracted) Luminance
(L) data set. I have used this format for some of my Drizzle-Captured
images - but I only use it when I know that I am NOT going to re-stack
the collected data in the likes of Registax. In other words, I will
purely be trying to create my final image using the likes of
PixelInSight to tweak the Curves and Histograms to suit. (From this you
can infer that PixelInSight, a very well-written piece of software) is
completely un-phased by the many different formats used by the FITS
specification).

It is in the post-processing of these multi-file, 16-bit data sets that
the greatest complications arise, because you now have to consider that
your data lives in (up to) four different locations.

However, it is the FitsInt mode that I have used most - simply because I
worked out a method that allowed me to easily re-align and re-stack the
four data sets in Registax (v3). What I did was, after sorting all the
images into appropriate sub-directories, and renumbering them to give
PROPER numerical nomenclature (shame on you, MEADE, for not implementing
a counting scheme that INCLUDED 'leading zeroes' so that a computer
could properly 'sort' a named sequence of files), I then first processed
the LUMINANCE data - where Registax had the best chance of creating a
well aligned stack of 'good' images. I saved the Process File that was
created by Registax (simply a text file describing the steps that were
applied to the selected image files) and edited it three times, once for
each of the RED, GREEN and BLUE data sets. I then reloaded each of the
R, G and B Process Files into Registax, and all the data was processed
according to the Luminance file. The final three resulting images (with
or without Wavelet processing, but all without Histogram processing)
were then RGB aligned (because atmospheric disturbances can cause slight
pixel-level displacements in each of the colour planes) before, again,
being saved as 16-bit TIFF or FIT images. My final stage was to take
these three images into PixelInSight and work on stretching the data
using Histograms and Curves, before combining to a final three-layer RGB
image - saved once as a FITS image and once as a BMP image (only 8-bit,
but needed to allow me to view it on-screen using standard Windows
slideshow software).

Now that Registax v4 has been released (and although I have downloaded
it, and read the much more useful PDF support documentation) it seems
that it will be much easier to post process the FitsInt data - providing
that the individual file sequences are properly named. From memory (and
this may well have been the case for Registax v3 as well - only the lack
of documentation meant that I never managed to figure it out for myself
!!), you need to get all of your RED image files named, numerically (and
you can't rely on the default numbering scheme provided by Meade's
Envisage software - because image xxxxx1.tif will be grouped alongside
xxxxx10.TIF, instead of alongside xxxxx2.tif, etc.) and with a trailing
'-R' at the end of the name, before the '.TIF' file type suffix.

The same applies to your G, B and L files. So you need a program like
Polybytes 'Sequentialize' software, so that your files appear something
like M27_03-0008-R.FIT (representing my method of identifying files by
name of object [M27_], image session number [03-] and actual image
number in  the sequence (starting from [0000], running up to [9999] -
use FIVE digits if you have to, though highly unlikely). The use of [-R]
(and appropriate [-G], [-B] and [-L] suffixes) is how I will now be
naming collected data - in this case representing that these images are
part of the RED (or G, B or L) data set (which would, in any case, be
stored in a \R subdirectory of a \SESSION 03 (in this case) subdirectory
of the \20061105 M27 sub-folder (the date of the imaging session (Nov
05, 2006), and the name of the object being imaged- M27) - all of which
exists in a folder dedicated to MEADE IMAGES in My Documents.

Any of my imaging directories therefore look like :-

\My Documents
..\Meade Images              (where all of my DSI imaging data lives)
....\_archived darks          (where I keep sets of Dark Frames, named
by the temperatures recorded at the time of capture)
....\_not yet sorted          (where I copy data prior to renaming and
moving to structured directories)
....\20061105 M27            (this helps keep all of the sub-folders
named by date and object)
......\Session 01            (which will have the same structure as
Session 03, shown below)
......\Session 02            (as for Session 01)
......\Session 03            (shown here with a detailed breakdown of
its internal structure)
........\_Processed          (this is where all of my post-processing
data will end up)
........\B                    (contains all of the RAW Blue data)
..........M27_03-0001-B.FIT
..........M27_03-0002-B.FIT    (etc.)
........\G                    (contains all of the RAW Green data)
..........M27_03-0001-G.FIT
..........M27_03-0002-G.FIT    (etc.)
........\L                    (contains all of the RAW Luminance data)
..........M27_03-0001-L.FIT
..........M27_03-0002-L.FIT    (etc.)
........\R                    (contains all of the RAW Red data)
..........M27_03-0001-R.FIT
..........M27_03-0002-R.FIT    (etc.)

Well, a long ramble (as usual) - but it may help someone !!

Cheers,
Niall Saunders
Clinterty Observatories
Aberdeen, SCOTLAND
From: J.A.Russo (jrusso@bellatlantic.net)
Thanks for your reply. Niall's comments did the trick and were very
informative. You're a great resource. Keep up the good work!
Joe

Scusa Sergio....mi era sfuggito questa tua segnalazione.
ottima cosa.
Ti ringrazio !

Io dopo aver provato vari formati e aver letto vari post qua e la, ho concluso che il formato più comodo e, allo stesso tempo, quello più ricco di informazioni dovrebbe essere Fits (non Fits3p) nella modalità "save all uncombined images".

Ho provato anche il formato Raw che però poi ti costringe ad un resize delle immagini per ottenerne una di dimensioni 640x480.

Senonché ho provato in questi giorni DeepSky Stacker rielaborando alcune pose di Andromeda prese con la Eos 400D e ottenendo, mi sembra, un risultato molto più realistico di quello prodotto da Maxim DL qualche giorno fa e postato nel forum. In allegato la nuova elaborazione.

Mi chiedevo quale sia il formato della DSI più adatto per la successiva elaborazione con DeepSky Stacker e come dovrebbe svolgersi l'elaborazione.

Ad esempio, il formato Fits produce, di ogni posa, 4 files, uno per ciascuna componente di colore (RLGB). Con DeepSky Stacker mi verrebbe di sommare quelle di ogni colore e poi combinarne i risultati.

Che ne dite?
Che ne dice il mio compagno di DSI Bensi?

Un saluto

Sergio

Bellissima immagine...spero un giorno di ottenerne una simile.

Io ritengo DeepSkyStacker quello che fa per me ch enon voglio troppi problemi ...

Devo essere sincero sono un po' sempliciotto e quando faccio il salvataggio dei vari frames (oltre che avere il risultato finale di Envisage) uso il semplicissimo e leggero JPG...forse con il loro valore di compressione sono poco duttili ...

Ho provato a fare delle prove con il Fits per Registax ma mi sono subito scocciato e impallato per il numero di frames rgb etc..

Mi piacerebbe mandare un sunto semplice e schematico di queste tipologie di formati compatibili con Envisage anche sul Forum ETX-LXD che ne dici.

Ciao
a risentirci

In effetti covo da tempo l'idea di fare una breve traduzione del testo che ho inserito nel post e magari integrarlo nel mio manuale per la DSI.
Vedo di farlo a breve.

Per quanto riguarda le riprese in Jpeg, M31 l'ho tirata fuori proprio da pose in Jpeg anche se si tratta di quelle della Eos400D a più alta qualità

Con la DSI, anche io all'inizio ho cominciato con il formato Jpeg, poi sono passato al BMP, poi ho iniziato a salvare ogni frame e a sommarli.

Però devo dire che, in effetti, lavorare con i Fits o con i Raw ti consente di tirare fuori un sacco di roba in più.

Molto carino DeepSky Stacker. Ho cominciato a usarlo con la Eos ma volevo appunto vedere come si comporta con le riprese della Meade.

Ciao

Sergio

Ad esempio, il formato Fits produce, di ogni posa, 4 files, uno per ciascuna componente di colore (RLGB). Con DeepSky Stacker mi verrebbe di sommare quelle di ogni colore e poi combinarne i risultati.
Che ne dite?

Si, e' il modo con cui si procede normalmente con le riprese LRGB prese singolarmente.

Senonché ho provato in questi giorni DeepSky Stacker rielaborando alcune pose di Andromeda prese con la Eos 400D e ottenendo, mi sembra, un risultato molto più realistico di quello prodotto da Maxim DL qualche giorno fa e postato nel forum. In allegato la nuova elaborazione.

Ahi ahi... sinceramente pensavo il contrario. Evidentemente la semplicita' di uso di Deepsky Stacker e' notevole e riesce a compensare una non perfetta conoscenza di Maxim DL. Comunque le due M31 sembrano molto simili, parlo dei dettagli della galassia e la magnitudine limite, trovo differente la morbidezza e la diversa tonalita' di colore, ma si tratta di due caratteristiche che normalmente si implementano alla fine del processo.

Ho visto solo ora l'altro tuo post sulla M31. Purtroppo utilizzando solo Astroart non so darti consigli sulla procedura di utilizzo dei dark frame con Maxim DL. Da quello che leggo in giro sul web, non tutti applicano il dark alle proprie riprese con la reflex digitale, molti lamentano infatti scarsi miglioramenti, perlomeno inferiori a quanto si ottiene con le CCD b/n raffreddate. Quanto al metodo di combinazione delle immagini, io ti consiglio la media e non la somma. Con quest'ultima, in soggetti che hanno parti molto luminose come il nucleo di M31, corri il rischio di saturare. La media ti consente di evitare questo rischio e comunque di ottenere il beneficio primario tanto ambito, ovvero il miglioramento del rapporto segnale/rumore (riduci la grana).

Comunque Sergio, continua cosi' con la EOS, credo che ti dara' soddisfazioni che difficilmente potrai avere con la DSI. Il segreto? Cielo buio + esposizione totale (come somma di subpose) di 60 minuti o superiore! Prova questo cocktail e facci vedere i risultati!

Buon lavoro!
Paolo