Separating the render method into an implementable class

[kamicut]

I am proposing that we separate the rendering function from sources to tiles into its own implementable class. Currently, there are no hooks to control how to render single band or multi-banded sources. This leads to ad-hoc recipes specific to certain catalogs.

This will enable us to have more controls over pre-processing, band selection and post-processing. render right now takes 3-band arrays and turns them into tiles. After talking with @mojodna, we think it could be the other way around, where single bands are the inputs to render. With some refactoring, we could think of inputs to rendering as a function of n bands that outputs an rgb tile. This would allow any catalog to provide single band or multi-band Sources and give us the flexibility to composite bands from different catalogs.

A preliminary plan (out of order):

• Move preprocessing to Sources, so a Source knows how to preprocess itself
• Make PixelCollection single-banded only
• Write render function examples that takes n x PixelCollection and turns that into a tile for 3-banded and 1-banded sources.

Potential drawbacks to this approach would be that marblecutter implementations moving forward would need to implement both a Catalog and a render method instead of just a catalog. This extra layer of indirection would make a user guide necessary. Another drawback is that this breaks compatibility with previous marblecutter implementations.

Anything I missed @mojodna?

[kamicut]

@mojodna Since read_window also takes a "recipes" argument, I wonder if each Source should declare its own read_window function (that could tie in a pre-process function). Unless there might be another way to remove the custom code path in read_window?