https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/PIPE2D-872 DRP 2-D Pipeline <p>It would be useful to expose the resampleKernelImage function from <a href="https://github.com/Subaru-PFS/drp_stella/blob/master/src/SpectralPsf.cc." class="external-link" rel="nofollow">https://github.com/Subaru-PFS/drp_stella/blob/master/src/SpectralPsf.cc.</a> This would enable me to use it in my testing and analysis, and to ensure that we are not introducing errors when moving from between analysis of the spots and final implementation in the pipeline.</p> <p>Additionally, it would be good to better understand the difference between resampleKernelImage function and bin_image function from base LSST code.</p> PIPE2D-872

Expose function resampleKernelImage to python

Task Normal Done Done price ncaplar Mon, 19 Jul 2021 20:07:25 +0000 Tue, 3 Aug 2021 20:22:06 +0000 Wed, 28 Jul 2021 14:40:22 +0000 0 3 <p><tt>lsst.afw.math.binImage</tt> puts the corner of the input image in the corner of the output image. <tt>pfs.drp.stella.resampleKernelImage</tt> puts the center of the input image in the center of the output image. Consider the following example:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &gt;&gt;&gt; <span class="code-keyword">import</span> numpy as np &gt;&gt;&gt; from lsst.afw.image <span class="code-keyword">import</span> ImageD &gt;&gt;&gt; from lsst.afw.math <span class="code-keyword">import</span> binImage &gt;&gt;&gt; from lsst.geom <span class="code-keyword">import</span> Box2I, Point2I, Point2D &gt;&gt;&gt; from pfs.drp.stella.images <span class="code-keyword">import</span> getIndices, calculateCentroid &gt;&gt;&gt; from pfs.drp.stella <span class="code-keyword">import</span> resampleKernelImage &gt;&gt;&gt; binning = 5 &gt;&gt;&gt; box = Box2I(Point2I(-50, -50), Point2I(50, 50)) &gt;&gt;&gt; image = ImageD(box) &gt;&gt;&gt; xx, yy = getIndices(image.getBBox()) &gt;&gt;&gt; image.array[:] = np.exp(-0.5*(xx**2 + yy**2)/5.43**2) &gt;&gt;&gt; lsst = binImage(image, binning) &gt;&gt;&gt; pfs = resampleKernelImage(image, binning, Box2I(Point2I(-10, -10), Point2I(10, 10))) &gt;&gt;&gt; calculateCentroid(image) namespace(x=-2.5493701622806684e-18, y=-1.1988050118056573e-17) &gt;&gt;&gt; calculateCentroid(lsst) namespace(x=-40.39999999998449, y=-40.39999999998449) &gt;&gt;&gt; calculateCentroid(pfs) namespace(x=-9.642385750780955e-18, y=-9.642172334948585e-18) </pre> </div></div> <p>We created a PSF directly in the center of the input kernel, but <tt>lsst.afw.math.binImage</tt> moved the center so that it's not even centered on a pixel. However, <tt>pfs.drp.stella.resampleKernelImage</tt> puts the center exactly where it should be. In the figure below, the original oversampled <tt>image</tt> is on the left, the <tt>lsst</tt> image is in the middle, and the <tt>pfs</tt> image is on the right.</p> <p><span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/13947/13947_centering.jpg" style="border: 0px solid black" /></span></p> <p> Could you perhaps comment on the results of the followign example</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> from lsst.afw.image <span class="code-keyword">import</span> ImageD from lsst.afw.math <span class="code-keyword">import</span> binImage from lsst.geom <span class="code-keyword">import</span> Box2I, Point2I, Point2D from pfs.drp.stella.images <span class="code-keyword">import</span> getIndices, calculateCentroid from pfs.drp.stella <span class="code-keyword">import</span> resampleKernelImagebinning = 10 box = Box2I(Point2I(-20, -20), Point2I(19, 19)) image = ImageD(box)xx, yy = getIndices(image.getBBox()) image.array[:] =np.ones((40,40))print(<span class="code-quote">'calculateCentroid(starting image): '</span>+str(calculateCentroid(image)))lsst = binImage(image, binning) pfs = resampleKernelImage(image, binning, Box2I(Point2I(-2, -2), Point2I(1, 1))) print(<span class="code-quote">'calculateCentroid(after binImage + getBBox() minimum ): '</span>+str(np.array([calculateCentroid(lsst).x,calculateCentroid(lsst).x])+20)) print(<span class="code-quote">'calculateCentroid(resampleKernelImage): '</span>+str(calculateCentroid(pfs))) plt.figure(figsize=(24,6))plt.subplot(131) plt.title(<span class="code-quote">'via binImage'</span>) plt.imshow(lsst.array,origin=<span class="code-quote">'lower'</span>) plt.axhline(1.5,color=<span class="code-quote">'black'</span>) plt.axvline(1.5,color=<span class="code-quote">'black'</span>) cbar=plt.colorbar(fraction=0.046, pad=0.04)plt.subplot(132) plt.title(<span class="code-quote">'via resampleKernelImage'</span>) plt.imshow(pfs.array,origin=<span class="code-quote">'lower'</span>) cbar=plt.colorbar(fraction=0.046, pad=0.04) plt.axhline(1.6666666666666667,color=<span class="code-quote">'black'</span>) plt.axvline(1.6666666666666667,color=<span class="code-quote">'black'</span>)</pre> </div></div> <p>which creates the figure `example_constant_array.png` and output of </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> calculateCentroid(starting image): namespace(x=-0.5, y=-0.5) calculateCentroid(after binImage + getBBox() minimum ): [1.5 1.5] calculateCentroid(resampleKernelImage): namespace(x=-0.33333333333333337, y=-0.33333333333333337)</pre> </div></div> <p>In this example I create a constant array, 40x40 which I resample into 4x4, assuming oversampling of 10. This is somewhat more similar to my case in which I always dowsample by integer value (in the previous example 101x101 gets downsampled by factor of 5 into 21x21). I am quite confused by the result from the pfs algorithm, whilst understanding lsst output - I just get constant image again.<br/>  </p> <p>The more I look at the algorithm I think that there is a 0.5 pixel difference between the two which is creating all this confusion, i.e., standard what is the index of pixel question.</p> <p>Because the image is constant, how the output image looks all comes down to how the output pixels overlap the input pixels. For the <tt>lsst</tt> image, all the output pixels overlap a full 10x10 pixels (the corner maps to the corner, and there's an exact multiple of the binning in the input image), and so the output image is constant. For the <tt>pfs</tt> image, not all output pixels are fully populated (the center maps to the center, which means 20,20 physical/<tt>LOCAL</tt> coordinate in the input maps to 2,2 physical/<tt>LOCAL</tt> in the output; therefore the column=2 physical/<tt>LOCAL</tt> output contains contributions from physical input columns 16 to 25 inclusive, so column=1 has 6 to 15, and column=0 has -4 to 5, but it is assumed there is no flux outside the physical bounds of the input image, which means -4 to -1 inclusive are zero, and only 0 through 5 inclusive are populated, hence it only gets 6/10 of the flux), and so the edges have 0.6 of the flux that the main image has, and the bottom-left corner has 0.6^2 = 0.36.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &gt;&gt;&gt; (pfs.array[1,1]/pfs.array[1,0])**-1 0.6 &gt;&gt;&gt; (pfs.array[1,1]/pfs.array[0,0])**-1 0.36 </pre> </div></div> <p>It occurred to me that your confusion might be due to being unaware of the pixel indexing conventions in use.</p> <p>We find it useful to associate images with two related indexing conventions. The first is the <tt>LOCAL</tt> convention, which you can think of as physical coordinates (not strictly accurate, but good enough for now), where the bottom-left pixel is <tt>0,0</tt>. For an image of size <tt>4,5</tt>, the <tt>LOCAL</tt> coordinates run from <tt>0,0</tt> to <tt>3,4</tt> (inclusive). The second is the <tt>PARENT</tt> convention, or logical coordinates, where the bottom-left pixel is <tt>x0,y0</tt> (often abbreviated as <tt>xy0</tt>). For an image of size <tt>4,5</tt> with an <tt>xy0</tt> of <tt>2,3</tt>, the <tt>PARENT</tt> coordinates run from <tt>2,3</tt> to <tt>5,7</tt> (inclusive).</p> <p>The <tt>PARENT</tt> convention is so-named because it's what we use when we want to refer to the coordinate system of the full image from which we've taken a sub-image. We can have an image of size <tt>100,100</tt>, and from it extract a sub-image, say of size <tt>4,5</tt> and with an <tt>xy0</tt> of <tt>2,3</tt>. When we operate on that sub-image (e.g., <tt>subImage.array<span class="error">&#91;y,x&#93;</span></tt>), we use <tt>LOCAL</tt> coordinates. When we want to talk about where something is in relation to the full image, we use the <tt>PARENT</tt> coordinates.</p> <p>You can use <tt>image.getXY0()</tt> to get the <tt>xy0</tt> of the image, and <tt>image.getBBox()</tt> to get the <tt>PARENT</tt> bounding box, and <tt>image.getBBox(lsst.afw.image.LOCAL)</tt> to get the <tt>LOCAL</tt> bounding box.</p> <p>When we have a kernel image (as in a convolution kernel), where the concept of the center is important (because it corresponds to zero shift, or the center of a PSF), we set <tt>xy0</tt> negative, so that <tt>0,0</tt> in the <tt>PARENT</tt> coordinate system is somewhere in the middle of our image (in the <tt>LOCAL</tt> coordinate system). So an image of size <tt>4,5</tt> with an <tt>xy0</tt> of <tt>-2,-3</tt> has <tt>PARENT</tt> coordinates that run from <tt>-2,-3</tt> to <tt>1,1</tt> (inclusive), and the "center" (the <tt>0,0</tt> pixel in the <tt>PARENT</tt> frame) is at <tt>2,3</tt> in the <tt>LOCAL</tt> frame.</p> <p>So when I say that "the center maps to the center", it means that the (center of the) <tt>0,0</tt> pixel in the <tt>PARENT</tt> frame of the input image maps to the (center of the) <tt>0,0</tt> pixel in the <tt>PARENT</tt> frame of the output image, and the borders of the output pixels on the input image follow from that. And "the corner maps to the corner" means that the (corner of the) <tt>0,0</tt> pixel in the <tt>LOCAL</tt> frame of the input image maps to the (corner of the) <tt>0,0</tt> pixel in the <tt>LOCAL</tt> frame of the output image, and the borders of the output pixels on the input image follow from that.</p> <p>One subtlety is that when we're binning by an even factor, we can't put the center of the input image directly on the center of the output image without sub-pixel sampling, which we don't want to do in the rebinning operation. Instead for even binning factors, when we recenter ((<tt>recenterOversampledKernelImage</tt>) we move the center of the PSF to <tt>-0.5,-0.5</tt> instead of <tt>0,0</tt> to account for this.</p> <p>Code changes look fine. Minor comment made.</p> <p>I apologize for not commenting here earlier. The changes are exactly as needed and described. Comment made by Paul was very helpful.</p> <p>Merged.</p> Relates PIPE2D-874 Development Rank 0|zzs8a0: Reviewers hassan Sprint 2DDRP-2021 A 7 Story Points 1.0