W3C home > Mailing lists > Public > public-tt@w3.org > May 2017

Re: Document Coordinate System intepretation

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 24 May 2017 08:42:24 -0600
Message-ID: <CACQ=j+cFC2eMX7car4kN2Xhedssqu0-aqvrNTn+K2brgUXRVSw@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Pierre-Anthony Lemieux <pal@sandflow.com>, "public-tt@w3.org" <public-tt@w3.org>
On Wed, May 24, 2017 at 8:36 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> I think I'm agreeing with both of you except to say that I do not think
> that storage pixels have any spatial dimensions at all – they are just
> colour tuples that can be addressed in a two dimensional array. Calling
> them "square" is useful only in the sense that, if they exist at all*, then
> when you multiply the number of them in each dimension by PAR you get the
> DAR.
>

Exactly.


>
> * The pixels might not exist, if for example a transformation processor is
> performing logical operations without mapping to an output raster of any
> kind. This is entirely feasible without a root container extent, if only
> percentage of root container units rh and rw are used, say.
>

Agreed.


>
> Not sure how much that helps, it's another mental view anyhow.
>
> Nigel
>
>
> From: Glenn Adams <glenn@skynav.com>
> Date: Wednesday, 24 May 2017 at 06:46
> To: Pierre-Anthony Lemieux <pal@sandflow.com>
> Cc: "public-tt@w3.org" <public-tt@w3.org>
> Subject: Re: Document Coordinate System intepretation
> Resent-From: <public-tt@w3.org>
> Resent-Date: Wednesday, 24 May 2017 at 06:47
>
>
>
> On Tue, May 23, 2017 at 11:19 PM, Pierre-Anthony Lemieux <pal@sandflow.com
> > wrote:
>
>> Hi Glenn,
>>
>> > hmm, it is the aspect ratio of the physical pixels that PAR applies to
>>
>> What do you mean by "physical pixels"? If the DAR and SAR are those of
>> the root container, then the PAR is also that of the root container,
>> not the physical display. In other words, both SAR and PAR apply to
>> the logical pixels of the coordinate system, completely independently
>> of the physical pixels.
>>
>
> I mean quasi-physical pixels, i.e., PAR pixels in the DAR space.
>
> Consider that all SAR pixels (pixels in the sample space) are square, then
> PAR scales such square (logical) pixel to a possibly non-square DAR pixel
> (pixels in the output space). Since we use "physical" in PAR, then when I
> refer to physical pixels here I am referring to whatever output pixels are
> produced by TTML rendering. These are quasi-physical in the sense that the
> still need to be mapped (possibly multiple times) to an eventual dot
> pattern on a physical display.
>
>
>>
>> > what I mean is that width divided by height selected by the document
>> processing
>> > context must equal SAR, and that SAR * PAR must still equal DAR;
>>
>> The only thing the document processing context can control by setting
>> the extent in pixel is the SAR. The DAR and the PAR are computed
>> according to the algorithm specified in Annex H, so no need to repeat
>> it.
>>
>
> Agreed. It is redundant to include "and PAR" in that cited text.
>
>
>>
>> Best,
>>
>> -- Pierre
>>
>> On Tue, May 23, 2017 at 10:09 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> >
>> > On Tue, May 23, 2017 at 10:50 PM, Pierre-Anthony Lemieux <
>> pal@sandflow.com>
>> > wrote:
>> >>
>> >> Hi Glenn et al.,
>> >>
>> >> Before I continue filing issues on PR #321, I thought I would confirm
>> >> (or not) my summary understanding of the document coordinate system as
>> >> currently proposed.
>> >>
>> >> - the coordinate system is in logical pixels
>> >
>> >
>> > yes, effectively in the storage (sample) coordinate space (as governed
>> by
>> > SAR)
>> >
>> >>
>> >> - the aspect ratio of each of the logical pixels is set by the value
>> >> of Pixel Aspect Ratio (PAR) of the root container
>> >
>> >
>> > hmm, it is the aspect ratio of the physical pixels that PAR applies to,
>> or,
>> > to be more precise, pixels in the display coordinate space (as governed
>> by
>> > DAR); logical pixels in the storage coordinate space (as governed by
>> SAR)
>> > have no aspect ratio per se;
>> >
>> >>
>> >> - the origin of the coordinate system is the top left corner of the
>> >> root container
>> >
>> >
>> > yes
>> >
>> >>
>> >> - the positive x-axis points to the right edge of the root container,
>> >
>> >
>> > yes
>> >
>> >>
>> >> while the positive y-axis points to the bottom edge of the root
>> >
>> >
>> > yes
>> >
>> >>
>> >> contain
>> >> - the extent of the root container in this coordinate system is set
>> >> either by (a) tts:extent if specified in "px" or (b) arbitrarily by
>> >> the document processing context such that the ratio of the width
>> >> divided by the height is equal to the computed Storage Aspect Ratio
>> >> (SAR) of the root container
>> >
>> >
>> > yes for (a), for (b), this is not exactly what I wrote, which is
>> >
>> > otherwise, the resolution of the root container region is determined
>> > (arbitrarily) by the document processing context in a manner that
>> respects
>> > the resolved values of SAR and PAR as determined by H.1 Aspect Ratios
>> above
>> >
>> > in saying that the resolved value of SAR be respected, what I mean is
>> that
>> > width divided by height selected by the document processing context must
>> > equal SAR, and that SAR * PAR must still equal DAR;
>> >
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> -- Pierre
>> >>
>> >
>>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>
Received on Wednesday, 24 May 2017 14:43:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:40 UTC