Mipmapping for canvas. Ideas and comments.
cberger at cberger.net
Wed Jul 22 10:15:49 CEST 2009
On Tuesday 21 July 2009, Dmitry Kazakov wrote:
> Well, yes. It's more theoretical and experimental issue =). Even
> colors filters would suffer much because of that. In theory we could
> ask a filter whether he could work with downsampled input and,
> conforming to it's decision, stop or continue running merge strategy
> on mipmapped tree. In theory...
> Mipmapping would create too much overhead here. Nevertheless, i think
> that our filter preview algo should support preview on downsampled
> image. I don't know how about all filters in Photoshop, but Color
> adjustment tools are cirtainly applied to downsampled image first. And
> only when you press OK, it applies as usual.
It's about previewing, I don't think users would see a problem if we first show
something not very accurate but quickly, and then later in the background
compute the real deal.
In fact we have three classes of filters:
* pixel-base (color adjustment...): their parameters aren't dependent on the
zoom level, results are going to be in 99% of the situation very close when
* kernels (blur...): the parameters are dependent of the zoom, but we can give
the zoom to the filter to adjust the parameter, it's likely to be insufficient to
give an accurate result
* demosaicing: zooming an unmosaiced image gives unexpected results anyway :)
but the filter always have to be computed at zoom = 100%
That said, the pyramid might not be the best answer to the preview problem.
And I am not sure if the drawbacks mentioned by Dmitry are not worth the
trouble. So we will have to keep being imaginative on the subject :) And
investigate region of interest, priority, or "scaling down to the zoom size
the layer, filtering, and the scaling up, compose, display, then in the
background the real deal", or whatever else idea we can come up with.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop