Re: RE: [png-list] CFD: Proposed new PNG public sTER chunk (MNG aspects)

> My conclusion is that sTER in a PNG stream must be ignored by MNG and
> that some chunk, e.g. sTEG, is necessary to make the whole MNG frame
> be stereo. This has all the compatibility features of sTER in PNG -
> when viewed on a sTEG capable decoder the result has half the frame
> width and is a full stereo animation, when viewed on pre-sTEG decoder
> the user sees a double width frame and must use the "cross eyed"
> technique to see the stereo.

This is what I'd prefer too. It makes the decoding a lot easier, and we all know 
libmng is already considered way too large by fellow open-sourcerers. Of 
course the whole handling of sTER/sTEG and pHYs/pHYg within libmng for 
this particular purpose (c)(w)ould be within conditionals.

If we go with the global sTEG/pHYg combination at the top of the MNG, which 
seems most logical, there wouldn't be a whole lot of code necessary. Just a 
couple API calls to discern a new (non)stereo flag and the pHYg/pHYs 
parameters. sTER/pHYs still apply too in libmng as it could be decoding a PNG 
as well.

Switching stereo-mode on and off would be possible. It's up to the displaying 
app to take action on the stereo-flag or not, and handle pixel-/canvas-
resizings based on pHYg/pHYs. This way a slideshow could contain regular 
images, interspersed with stereo-images.

Within a MNG sTER/pHYs would be ignored and the existence of a sTEG 
chunk plus any pHYg data would be available for the outside world. Within a 
PNG/JNG the existence of a sTER and the pHYs data would be available.

Gerard


--
Send the message body "help" to [email protected]