filtering 16-bit samples

On 2017-01-14 18:43, John Bowler wrote:
> The problem posed by the filtering for 16-bit components is that, as
> you say, the filtering only applies at the byte level, so for the
> sequence of two pixels:
>
>      | R1Hi | R1Lo | G1Hi | G1Lo | B1Hi | B1Lo | A1Hi | A1Lo |
>      | R2Hi | R2Lo | G2Hi | G2Lo | B2Hi | B2Lo | A2Hi | A2Lo |
>
> The filter algorithms compare [x1Hi]x[x2Hi] and [x1Lo]x[x2Lo}.
This has always been an issue in PNG, and i periodically wonder about 
new filter methods specifically optimised for 16bit samples, which
a) rearrange each scanline into two fields, like this

	| R1Hi | G1Hi | B1Hi | A1Hi | R2Hi | G2Hi | B2Hi | A2Hi | etc

	
	| R1Lo | G1Lo | B1Lo | A1Lo | R2Lo | G2Lo | B2Lo | A2Lo | etc


and then
b) apply one of the existing filters (including none) to each field. The 
Hi and Lo fields might well compress better if filtered differently.

I haven't proposed it because I never took the time to run experiments 
and see how it worked out in practice with various images. Has anyone 
else wondered about this?

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi