On Wed, 10 Jun 2009, Hans Verkuil wrote: > On Wednesday 10 June 2009 18:02:39 Guennadi Liakhovetski wrote: > > This question - how S_FMT and S_CROP affest image geometry - has been > > discussed at least twice before - that's only with my participation, > > don't know if and how often it has come up before. But the fact, that in > > two discussions we came up with different results seems to suggest, that > > this is not something trivially known by all except me. > > > > First time I asked this question in this thread > > > > http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg00052.html > > > > and Mauro replied (see above thread for a complete reply): > > > > On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote: > > > On Wed, 7 Jan 2009 10:14:31 +0100 (CET) > > > Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote: > > > > [snip] > > > > > > For example on mt9t031 > > > > binning and skipping are used for that. Whereas CROP uses the current > > > > scaling configuration and selects a sub-window, so, once you've done > > > > S_FMT to 320x240, a crop request for 640x480 might well fail. > > > > > > I also understand this way. You cannot crop with a resolution bigger > > > than what you've selected. > > > > (Let's call this statement M1:-)) > > If I read the spec correctly, in particular section 1.11.1, then cropping > comes before scaling, so you can crop to 640x480 (S_CROP) and scale that to > 320x240 (S_FMT). S_FMT scales the cropped rectangle. This is my understanding of how it's supposed to work as well. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
