Two drawback for me in PI

[fjabet]

Hello,

I've been using PI on a regular basis since three years now, and I'd like to raise two issues that are quite important to me.

First is the fact that preprocessing in PixInsigh doesn't preserve the WCS data in the Fits header. I use Aladin to analyse the images, and I can't understand why is it so.
Basically I need to relaunch the plate resolution after processing although information was already present from the beginning.
As the digital sampling information is present in the header (automatic acquisition done with MaximDL+Pinpoint or Prism), neither image integration nor cropping should destroy this WCS header.

The second is blooming correction. This should be included inside PI. The HDR process is not an option to as it spoils acquisition time and damage the final SNR.
I do not agree about objections regarding the "PI philosophy" stating that blooming removal is merely like PS stamp tool. Either we have a pure scientific application and then you can remove a big part of the processes that aren't respecting the initial data anyway, or then you provide tools to the market of imagers willing to do nice images and deblooming is a must have.

I may also include in this the lack of ability to define manually masks.

Frédéric Jabet.

[georg.viehoever]

Hi Frederic,

you can transfer the FITS keywords using the FITS Keywords tool from the file menu. Open it with your already solved files, and then drag it to your processed file. Of course, this does not work if you rotate, mirror, distort, crop, rescale your image in any way, but otherwise it should work fine.

I leave it to others to comment on your debloom and mask requests.

Georg

[Juan Conejero]

Hi Frédéric,

First is the fact that preprocessing in PixInsigh doesn't preserve the WCS data in the Fits header.

The ImageCalibration process preserves all existing FITS header keywords and image properties. The StarAlignment process also preserves all headers, although WCS keywords are invalidated by the geometric transformations applied for image registration, and so they are kept just as information about a previous state of the image. One could argue that SA might apply the same transformations to recompute WCS parameters automatically, and this functionality could be implemented as an option, but this is not the optimal solution in general. SA does not necessarily apply a linear transformation (for example, with local distortion corrections enabled), which can make recalculation of standard WCS parameters very difficult or impossible in many cases. Even with purely linear transformations, the result would be inaccurate as a result of pixel interpolations and other factors. When necessary, the best solution in this case is to solve the registered images astrometrically with the ImageSolver script, which replaces WCS keywords with newly calculated values.

neither image integration nor cropping should destroy this WCS header.

ImageIntegration does not preserve WCS data present in the integrated frames, mainly because that would be incorrect in most practical cases. Even in the hypothetical best possible case, where all of the integrated images would have been acquired centered exactly at the same celestial coordinates, and exactly with the same orientation on the sky, the integrated image should be solved astrometrically for optimum accuracy. This is true also if all of the individual integrated frames have been solved again before integration---which, on the other hand, means to n-plicate the same task without a valid reason. As noted above, the ImageSolver script by Andrés del Pozo is an excellent plate solver, and it is readily available in PixInsight.

The second is blooming correction. This should be included inside PI. The HDR process is not an option to as it spoils acquisition time and damage the final SNR.

Integration of unsaturated data (by acquisition of shorter exposures or by other means) is one of the two only valid solutions to the bloomings problem. The other one is acquisition of data with differing orientations and statistical rejection of blooming artifacts during integration. The rest of "solutions" consist of painting the image with fake data. Bear in mind that fake data do not increase the SNR of the image, mainly because they cannot provide new signal. The excess of noise on blooming areas can be dissimulated easily with masked noise reduction.

Either we have a pure scientific application and then you can remove a big part of the processes that aren't respecting the initial data anyway, or then you provide tools to the market of imagers willing to do nice images and deblooming is a must have.

I disagree completely with this vision. Image processing, when applied with the necessary knowledge and documentary criteria, based on properties of the data and of the represented objects, does respect the acquired data. When used this way, image processing is a means to transform the acquired data into meaningful information about a subject of nature. This clearly excludes any form of arbitrary intervention without the above-mentioned criteria, including most manual manipulations that are unfortunately so prevalent today.

One of our aims with PixInsight is versatility: it can be used at many different levels. You can use it just as an image processing application, or you can use it as a development platform, where new tools can be created to solve specific data and signal processing problems. In this sense, PixInsight can be a valid platform for academic research work as well as for astrophotographical work, with the many intersections that exist between both contexts. What PixInsight is not intended to be is an image retouching application; there are plenty of solutions of that kind in the market, but we are definitely not interested in doing that.

Lastly, "the market" is not necessarily one of the factors that guide our development work.

[fjabet]

I do use the plate solver after processing, nevertheless that's one more step. But that is not that important.

I absolutly disagree regarding the approach you have regarding the blooming correction. Sure that this cosmetic correction doesn't any more value than easthetic and doesn't create any information. As it is the case for some process such as the cosmetic correction process.
But an important part of your users does use PI to make nice picture rather than science, and they do need to correct blooming somehow, and doing more exposure at 90° to make an HDR correction is not a valid option. When having a full 32 bits processing, it's quite a drawback to have to export in 16 bits to MaximDL, PS or whatever application just to correct bleeding. It is the same thing regarding fully customizable mask. Doing a specific mask using pixel math with the intensity mask is quite a hassle, not to mention to make it in PS and reimport.
Giving the opportunity to use tools that you may not use for scientific images doesn't mean that you have to use them. But for many users that may not share your utilization of PI, it would be rather useful.
The "market" is also your existing users, and you definitly have to listen to them.

[oldwexi]

Hi Fjabet!
O.k., you have a camera with technical disadvantages which destroy correct data with blooming stripes.

I would like to understand what you want to put on the place where your camera destroys original data,
on the blooming stripes? At the moment I dont care which software should do it - if you dont have
real data - any software, which should solve the technical problem of your camera, have to invent and paint!!!!
This has nothing to do with image processing, this is simply faking of images, where does this faking stop??
What you want has nothing to do with image processing, outside science - why you dont paint the complete image?

As you deny to rotate the camera by 90 degree, where should the data, and which data(?) come from to replace the white stripes?
This is the main question! What about the galaxies, stars, planetary nebula, IFNs which have been eraded by the
blooming camera?

Gerald rotating

[fjabet]

Once again, this is your stand. Duplicating a few columns to correct bleeding isn't an issue in my opinion and for my application. I won't keep me away from a small PN, and yes, I may loose a small galaxy or star in the process, but this is my choice. If there is a bloomin gcorrection, nobody forces you to use it.
I decided that I prefer the risk to loose a star than to have huge bleeding on my image.
I delibaratly expose dozens of hours on an objet to get a very good SNR this is not to loose time on 90° short exposure that will in the end degrade it. Anyway I'm fully automated and I don't intend to invest in a rotator.

I'm not the only one to wish a blooming correction in PI, do a search.

I am quite disappointed actually by Juan stand point and as a software editor myself, I'm quite puzzled as well. At some point you have to choose : either you play it the purest of all and you go open source, or you charge licence and you do have customers and a market, and you listen to them.

[oldwexi]

Hi Fjabet!
I would like to find a solution with maybe some processes
to replace the stripes  with "nice data", but thats not detailed enough.

Cant start trying before you answer the question:
What data in detail do you want to be put into the white stripes??


Gerald

[fjabet]

White noise with the same standard deviation as the image background sounds fine to me.

[llpastro]

What data in detail do you want to be put into the white stripes??

The way Maxim DL and CCDStack handle it would be fine for me.

Larry

[pfile]

i don't know what a "software editor" is but if you are developer, pixinsight is an open platform and there's nothing stopping you (or anyone else) from writing a process or a script that invents data and pastes it over the blooms.

rob