On 08/01/2016 02:29 AM, Philipp Zabel wrote:
Am Donnerstag, den 28.07.2016, 16:09 -0700 schrieb Steve Longerbeam:
Now split the frame in half and suddenly pixel x' = 640 is the start of a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over the edge of the source image.
Here's where we part.
The 320x200 --> 1280x800 conversion is split into two 160x200 --> 640x800 conversions. The DMA controller and ipu_ic_task_init() are given those width/height dimensions, not the dimensions of the original images. So this is simply two separate 160x200 --> 640x800 conversions. The only difference from a true 160x200 --> 640x800 image conversion is that the DMA controller must be given the stride lengths of the original 320x200 and 1280x800 images.
The rsc for the 160x200 --> 640x800 conversions is
x = x' * (160-1)/(640-1) = x' * 8192/rsc, so rsc = 32923
So original horizontal position 640 is really x' = 0 of the second conversion, which is sampled at x = 0 of the second conversion. And the pixel at x' = 1279 is really x' = 639 of the second conversion, which is sampled at x = 639
- 8192/32923
= 158.98, which does not read over the edge of the source tile.
My bad, I somehow thought that the scaling factor is calculated per image (as it IMHO should be), not just per tile.
Of course in that case you won't ever read over the edge, but on the other hand the visual problems are worse because you underestimate the scaling factor and introduce a sharp edge at the center: even if the source pixel step per target pixel step is a fraction, between pixels width/2-1 and width/2 there's always a whole source pixel step.
Take the extreme example of scaling 32x32 to 1080x1080 pixels. The ideal source pixels for x' = 519 and 520 should be x = 14.911 and 14.939, respectively. Due to tiling they will be x = 15 and 16, introducing a sharp seam in the otherwise blurry mess.
I think you mean at x' = 539 and x' = 540.
But yes I agree. Due to tiling, at x' = 539, the input pixel is sampled at x = 15. If the interpolation were to continue (no tiling), at x' = 540, the input pixel would be sampled at (31/1079)*540 = 15.514. Instead, because of tiling, there is a discontinuity in the interpolation (it is reset), beginning again at x' = 0 (540), which is sampled at x = 0 (16).
The only way I can think of to resolve this problem is to add some width to the output tiles such that the interpolation completes a full span between input position w - 2 and w - 1. That is, add to w' until floor(F*w') increments to the next whole integer, where F = (w-1)/(w'-1) is the scaling factor.
But that will likely cause the next tile DMA addrs to fail to fall on the IDMAC 8 byte alignment.
That said, I _have_ noticed seams, but I have always attributed them to the fact that we have a discontinuity in color-space conversion and/or resize interpolation at the boundary between tiles.
I've also found that the seams are quite noticeable when rendered to a display overlay, but become significantly less pronounced if the images are converted to a back buffer, and then page-flipped to front buffer when the conversion (all tiles) completes.
I don't know what to make of this. Maybe it is a timing issue and what you are actually seeing is tearing between tiles of different frames?
Yes, that's always been my assumption, a scan-out contains a mix of tiles from different frames, when page-flip is not used.
Steve