Filters in the Context of Image Compression

Hey all! I’m looking at the new filter functionality, and it looks awesome. I have a question though! I know I’ve talked with you all before about adding JPEG compression. With the new filters, I’m trying to figure out how I would implement that.

I’m thinking about starting with PNG actually, since that algorithm is a little more straightforward. (I’m not even going to worry about interleaving at the moment … ) Since PNG compression uses two steps, a filter step and a compression step, I’m assuming I’d have two filters? Is that the right way to think about the way that filters work in TileDB?


– Christina

Hi Christina,

The TileDB filter design may not be able to easily implement the filtering step of PNG processing. The current design is more meant for operating on opaque chunks of bytes. Generalized compression is a good fit, but any sort of filtering that requires knowledge of position in the domain (i.e. if the PNG filter needs to know neighboring pixel values) is not easily doable at this point. At most the filter design allows you to operate on individual attribute cells, but provides no information about the cell’s location in the domain.

On our roadmap (probably not until 1.6) are more customizable filters, including filters that have finer-grained knowledge of the domain.

Hope this helps,


Okay thank you! I’ll look at it more closely.