Honored Contributor
Honored ContributorHi Niki,
Which version of the Scaler were you using for this work? If it was Scaler I or Scaler II 10.1 (or Scaler II 11.0 with old software code) then I might have an idea why the Altera coefficients looked so horrible for the 8-tap upscale, and why phase 15 was shifted by 2 taps instead of 1 tap. It comes down to how the Scaler I and 10.1 Scaler II calculate the required phase for each output pixel for a given scaling ratio. For these versions the equation (for hozontal phase) is: phase = (((output_pixel_index * input_width) % output_width) *total_phases)/ max(input_width,output_width) The integer arithmetic used in the implementation adds an implicit floor function to the result. The numerator will vary in the range 0 -> (output_width - 1)*total_phases. If output width is greater than input width the final result will range between 0 and total_phases-1, as one would expect. If however the input_width is larger then the range will be reduced - e.g. if we are downscaling by a factor of 2x we will only use half the available phases. The larger the downscale, the smaller the usable phase range becomes. Because Altera was aware of this issue (it is my understanding that it was a deliberate optimisation to work around the HLS tool used to write the Scaler I rather than a bug) the coefficient generation code they provide compensates for the reduced phase range. However, it assumes that the number of taps you are using is indicative of the scaling ratio i.e. if you use 8-taps for Lanczos 2 is assumes you are doing a 2x downscale. In this case it will compress the useful phases (up to a shift of one tap) into the first half of the phase range. It will generate values for the other phases too, but these will have shifts greater than one tap, as you saw. This is fine if you acutally do a 2x downscale - as your results showed - you just get a bit less granularity in the phase shift. However, if you do an upscale the phase equation will be able to give results beyond the first half of the phase range, and you will get all sorts of horrible phase shifts and your output will look horrible. The first release of the Scaler II was a quick port of the existing algorithm to HDL from the internal HLS language and so it carried this optimisation over. However, for the 11.0 release there was time to look at this issue and fix it. If you check the 11.0 user guide it should give the following equation for phase for the Scaler II: phase = (((output_pixel_index * input_width) % output_width) *total_phases)/ output_width Now the full phase range is always accessible, no matter the scaling ratio. The coefficient generation code has also been altered to take this into account, so (hopefully) the really horrible upscale you saw for 8-taps Lanczos 2 should not happen now. Sorry for the long reply. Hopefully this was the cause of the strange things you saw (if you were using Scaler II 11.0 and the latest software code then I don't know what caused it). Regards, Kieron
