Before we improve the algorithm, I would suggest that we put better tests in place. One idea I had was that instead of using real tiles fetched from CDS or from hips-extra, we would introduce a session-scoped pytest test fixture (see https://docs.pytest.org/en/latest/fixture.html ) that generates a few tiles from scratch and fills the pixel values with something that's good for drawing tests.
E.g. we could just fill with constant values, like 42, or we could fill the tile pixels with their sky longitude or latitude image. Then we could use those tiles for drawing, and know what we expect / want in the output (again: a constant of 42, or a sky image with longitude / latitude as pixel values. And we can add asserts on pixels at the edges and corners of tiles.
@adl1995 - I think before you add this test, you'll have to implement / fix some things mentioned in other PRs / issues: Tile I/O and Tile cache and helper functions to generate some HiPS data.
To fix the actual issue mentioned of getting too high values at tile edges, something like this might fix it, i.e. only fill pixels that are still at 0:
cdeil
commented
7 years ago
I'm filing a few follow-up issues to things seen / discussed in #30 .
One point is that as can be seen in the docs example (https://github.com/hipspy/hips/pull/30#issuecomment-312290956), there are white lines at the edges of tiles currently, because we simply sum up projected tile images.
Before we improve the algorithm, I would suggest that we put better tests in place. One idea I had was that instead of using real tiles fetched from CDS or from hips-extra, we would introduce a session-scoped pytest test fixture (see https://docs.pytest.org/en/latest/fixture.html ) that generates a few tiles from scratch and fills the pixel values with something that's good for drawing tests.
E.g. we could just fill with constant values, like 42, or we could fill the tile pixels with their sky longitude or latitude image. Then we could use those tiles for drawing, and know what we expect / want in the output (again: a constant of 42, or a sky image with longitude / latitude as pixel values. And we can add asserts on pixels at the edges and corners of tiles.
@adl1995 - I think before you add this test, you'll have to implement / fix some things mentioned in other PRs / issues: Tile I/O and Tile cache and helper functions to generate some HiPS data.
To fix the actual issue mentioned of getting too high values at tile edges, something like this might fix it, i.e. only fill pixels that are still at 0:
I don't know if that works or if that will introduce other issues at the edges.