Activity › Forums › Astrosoftware › Astro Pixel Processor › Error: java.lang.NegativeArraySizeException › Reply To: Error: java.lang.NegativeArraySizeException
“In my own data processing for large telescopes, I first subtract the background in all mosaic panels and make the background zero in all panels. This handles the additive term. Then I conduct aperture photometry on stars in the panels, and use the common stars in the overlapping region to adjust the brightness of the panels. This handles the multiplicative term. Unfortunately, this only works on images with primarily point-like objects and with images that are very well flattened. Amateur images are usually not like this, unfortunately.”
Yes, for amateur images this is not feasible. I do understand your workflow.
“In my naive imagination, one may try to use the histograms in the overlapping region between two panels, and match both the central locations and the widths of the histograms. The match of the central location is an additive term, and the match of the width is a multiplicative term. For this to work very well, the panels have to be well calibrated and linear. Noise may add to the width of the histogram, and it can confuse this process.”
Indeed, the data needs to be linear and well calibrated. Noise is an important factor, since dispersion and noise values are correlated. Data that is really flat and well calibrated will have a very high correlation for the dispersion and noise values. If the data is not perfectly flat or has a a lot of structure due to nebulosity then the correlation is much lower in my experience.
In 5) normalize, you’ll notice that I have implemented 2 normalization modes
1) regular
2) advanced
The regular normalization mode, calculates lokation and dispersion values for the whole frame. This is the conventional/naive method and probably similar to what other programs do.
The advanced mode actually does what you are proposing in
“In my naive imagination, one may try to use the histograms in the overlapping region between two panels, and match both the central locations and the widths of the histograms. The match of the central location is an additive term, and the match of the width is a multiplicative term.”
For each frame the lokation and dispersion values are calculated on the area that exactly overlaps with it’s reference frame and are compared to the lokation and dispersion values of the same overlap area of the reference frame. So the advanced mode compares the exact same area’s after registration, so the normalization is done on the exact same histograms. It really works well and also works in mosaic mode. In mosaic mode, this means each panel has it’s own reference. This is possible due to the creation of registration paths in the mosaic mode. To be able to correcly compare dispersion in this advanced mode, the registration of the data is done using nearest neighbour interpolation since that actually conserves the noise characteristics of the data.
“If you don’t mind sharing the method for the current multiplicative and additive adjustments in APP, I may be able to suggest a method or two that can do both simultaneously.”
I don’t mind at all, I’ll try to send you the information with the formulas that I use within the next couple of days. Subtracting the lokation(background) and then adjusting for dispersion of the data is what’s happening in APP as well, by the way. So for each frame, it’s lokation is subtracted, then the data is multiplied, so the dispersion of the frame becomes the same as the dispersion of it’s reference. And finally, the reference lokation is added. So the frame and it’s reference will have the same lokation and dispersion afterwards in the overlap areas, which is a much better way to normalize than the regular/naive mode. I have some examples of this in my presentation, did you see those?

