Part of #38 combined the conversion from a .RGBA texture (MxNx4) to a .R texture (2Mx2N) with the subsequent cropping step. The RGBA texture is used since it conveniently stores all 4 sub-pixels of a Bayer CFA at one spatial coordinate using 4-vector while also providing performance benefits. The conversion back to the .R texture is done since the final image is a .R texture (a flattened Bayered image).
This had a subtle bug I missed the first time around in the following lines:
Nothing ensure that pad_left and pad_top inside convert_to_bayer is a multiple of 2. Originally, as used by crop_texture this was not a problem since pad_left and pad_top were used directly to index into the .R texture so the division by 2 was not needed. The division by 2 is needed since the RGBA texture indexes by Bayer CFA repeat units, rather than individual sub-pixels (i.e. RGBG instead of R, G, B, or G).
Certain images I've found end up requiring pad_left and/or pad_top to be odd, meaning that the indexing needing is no longer aligned and couldn't be performed in the .RGBA image.
Profiling the change, the difference in speed between doing the steps sequentially (as previously done) versus together did not yield a measurable difference in performance. So rather than fiddle with the padding math, I undid the portion of the PR that changed how convert_to_bayer worked.
Part of #38 combined the conversion from a .RGBA texture (MxNx4) to a .R texture (2Mx2N) with the subsequent cropping step. The RGBA texture is used since it conveniently stores all 4 sub-pixels of a Bayer CFA at one spatial coordinate using 4-vector while also providing performance benefits. The conversion back to the .R texture is done since the final image is a .R texture (a flattened Bayered image).
This had a subtle bug I missed the first time around in the following lines:
Nothing ensure that
pad_leftandpad_topinsideconvert_to_bayeris a multiple of 2. Originally, as used bycrop_texturethis was not a problem sincepad_leftandpad_topwere used directly to index into the .R texture so the division by 2 was not needed. The division by 2 is needed since the RGBA texture indexes by Bayer CFA repeat units, rather than individual sub-pixels (i.e. RGBG instead of R, G, B, or G).Certain images I've found end up requiring
pad_leftand/orpad_topto be odd, meaning that the indexing needing is no longer aligned and couldn't be performed in the .RGBA image.Profiling the change, the difference in speed between doing the steps sequentially (as previously done) versus together did not yield a measurable difference in performance. So rather than fiddle with the padding math, I undid the portion of the PR that changed how
convert_to_bayerworked.