Update of /cvsroot/dirac/compress/doc/latex_spec
In directory sc8-pr-cvs12.sourceforge.net:/tmp/cvs-serv7886
Modified Files:
sourcepresets.tex state-macros.tex vidsys.tex
Log Message:
Refactored the source parameter appendix to get rid of
remaining conversion
artefacts.
Index: sourcepresets.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/sourcepresets.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** sourcepresets.tex 23 Apr 2007 14:52:01 -0000 1.3
--- sourcepresets.tex 24 Apr 2007 09:35:00 -0000 1.4
***************
*** 1,2 ****
--- 1,3 ----
+ subsection{Source parameter presets}
label
***************
*** 97,101 ****
2 & PAL & 2
- EBU Tech 3213 & 1 - SDTV & 0 - TV \
hline
! 3 & D-Cinema & 3 -
CIE XYZ & 2 - YCgCo & 3 - DCI \
hline
end
--- 98,102 ----
2 & PAL & 2
- EBU Tech 3213 & 1 - SDTV & 0 - TV \
hline
! 3 & D-Cinema & 3 -
CIE XYZ & 2 - YCoCg & 3 - DCI \
hline
end
***************
*** 154,157 ****
caption{Transfer function
presets}label{table:transfervalues}
end
-
- [Must explain all these presets]
No newline at end of file
--- 155,156 ----
Index: vidsys.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/vidsys.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** vidsys.tex 23 Apr 2007 14:52:01 -0000 1.7
--- vidsys.tex 24 Apr 2007 09:35:00 -0000 1.8
***************
*** 1,4 ****
--- 1,8 ----
label
+ begin{informative*}
+ subsection{Video systems model for interpreting source
parameters (Informative)}
+ label
+
The interpretation of sequence source parameters (Section
ref)
by a display mechanism interfacing with a compliant
decoder is non-normative. However, it
***************
*** 7,13 ****
accurate display parameter information is encoded to
maximise the
quality of displayed video.
!
! begin{informative*}
! subsection
All current video systems use the following model for
luminance/chrominance
(`YUV')coding of RGB values (computer systems often omit
coding to and from YUV).
--- 11,15 ----
accurate display parameter information is encoded to
maximise the
quality of displayed video.
! subsubsection
All current video systems use the following model for
luminance/chrominance
(`YUV')coding of RGB values (computer systems often omit
coding to and from YUV).
***************
*** 52,56 ****
$ChromaFormat$ value.
! subsubsection{Conventional YUV coding}
In conventional YUV coding, the $E_Y$, $E_$ and
$E_$ values are
mapped to a range of integers denoted $Y$, $C1$ and $C2$
within this
--- 54,58 ----
$ChromaFormat$ value.
! paragraph{Conventional YUV coding\}
In conventional YUV coding, the $E_Y$, $E_$ and
$E_$ values are
mapped to a range of integers denoted $Y$, $C1$ and $C2$
within this
***************
*** 62,66 ****
to $E_R$, $E_G$, $E_B$ and thence to R, G and B.
! subsubsection{YCoCg coding}
The E values can be viewed as something of a mathematical
abstraction.
For example in digital display devices, R, G and B values
are specified
--- 64,68 ----
to $E_R$, $E_G$, $E_B$ and thence to R, G and B.
! paragraph{YCoCg coding\}
The E values can be viewed as something of a mathematical
abstraction.
For example in digital display devices, R, G and B values
are specified
***************
*** 78,82 ****
ref. This supports efficient lossless RGB
coding.
! subsection{Signal range}
label
--- 80,84 ----
ref. This supports efficient lossless RGB
coding.
! subsubsection{Signal range}
label
***************
*** 114,118 ****
end
! subsection
label
The colour primaries allow device dependent linear RGB
colour
--- 116,120 ----
end
! subsubsection
label
The colour primaries allow device dependent linear RGB
colour
***************
*** 170,176 ****
encoded primaries and display primaries is not done.)
! subsection
label
! subsubsection{Conventional YUV coding}
Unit-scale luma and chroma values $E_Y$, $E_$ and
$E_$ should be
--- 172,178 ----
encoded primaries and display primaries is not done.)
! subsubsection
label
! paragraph{Conventional YUV coding\}
Unit-scale luma and chroma values $E_Y$, $E_$ and
$E_$ should be
***************
*** 192,196 ****
end{eqnarray*}
! subsubsection{YCoCg coding}
In the case of YCoCg coding, integer $I_R$, $I_G$, $I_B$
should be directly computed from
the decoded $Y$, $C1$ ($Co$) and $C2$ ($Cg$) values by
--- 194,198 ----
end{eqnarray*}
! paragraph{YCoCg coding\}
In the case of YCoCg coding, integer $I_R$, $I_G$, $I_B$
should be directly computed from
the decoded $Y$, $C1$ ($Co$) and $C2$ ($Cg$) values by
***************
*** 228,233 ****
respectively..
! subsection{Transfer characteristics}
! subsubsection{TV transfer characteristic}
Denoting R or G or B as `$L$' (light) and $E_R$, $E_G$,
$E_B$ as
--- 230,235 ----
respectively..
! subsubsection{Transfer characteristics}
! paragraph{TV transfer characteristic\}
Denoting R or G or B as `$L$' (light) and $E_R$, $E_G$,
$E_B$ as
***************
*** 249,253 ****
NTSC systems use the `TV' transfer characteristic above.
! subsubsection{Extended Colour Gamut}
ITU-R BT 1361, `Worldwide unified colorimetry of future TV
systems'
--- 251,255 ----
NTSC systems use the `TV' transfer characteristic above.
! paragraph{Extended Colour Gamut\}
ITU-R BT 1361, `Worldwide unified colorimetry of future TV
systems'
***************
*** 272,281 ****
an extended colour gamut.
! subsubsection
A linear transfer characteristic has $f(x)=x$.
!
! subsection{Frame rate}
The ratio of the frame rate values $FrameRateNumerator$
and $FrameRateDenominator$
encodes the intended rate at which frames should be
--- 274,282 ----
an extended colour gamut.
! paragraph{Linear\}
A linear transfer characteristic has $f(x)=x$.
! subsubsection{Frame rate}
The ratio of the frame rate values $FrameRateNumerator$
and $FrameRateDenominator$
encodes the intended rate at which frames should be
***************
*** 284,313 ****
$TopFieldFirst$ flag.
! subsection{Aspect ratios and clean area}
! The PIXEL_ASPECT_RATIO value of an image is the ratio of
the intended
spacing of horizontal samples (pixels) to the spacing of
vertical
samples (picture lines) on the display device. Pixel
aspect ratios are
fundamental properties of sampled images because they
determine the
displayed shape of objects in the image. Failure to use
the right value
! of PIXEL_ASPECT_RATIO will result in distorted images
– for example,
! circles will be displayed as ellipses and so forth.
!
!
! Some HDTV standards and computer image formats are defined
to have pixel
aspect ratios that are exactly 1:1.
! The clean area is intended to define an area within which
picture
! information is subjectively uncontaminated by all edge
transient (and
! other) distortions. It may only be appropriate to display
the clean area
! rather than the whole picture, which may be distorted at
the edge.
! The top-left corner of the clean area has coordinates
(CLEAN_TL_X,
! CLEAN_TL_Y) and dimensions CLEAN_WIDTHxCLEAN_HEIGHT.
! The clean area and the pixel aspect ratio determine the
! IMAGE_ASPECT_RATIO which is the ratio of the width of
the intended
! display area to the height of the intended display area.
! Given two separate sequences, with identical
IMAGE_ASPECT_RATIO, if the
top left corner and bottom right corners of their clean
apertures are
coincident when displayed, then the images as a whole
should be exactly
--- 285,320 ----
$TopFieldFirst$ flag.
! subsubsection{Aspect ratios and clean area}
! The aspect ratio of an image is the ratio of the intended
spacing of horizontal samples (pixels) to the spacing of
vertical
samples (picture lines) on the display device. Pixel
aspect ratios are
fundamental properties of sampled images because they
determine the
displayed shape of objects in the image. Failure to use
the right value
! of will result in distorted images for example,
! circles will be displayed as ellipses and so forth. HDTV
standards and
! computer image formats are generally defined to have
pixel
aspect ratios that are exactly 1:1.
! The clean area defines an area of pixels within the
picture which
! should be displayed -- other pixels outside the area
should not be
! displayed. In particular, the clean area can be used to
suppress artefacts
! near the picture edges: at high levels of compression it
may only be appropriate
! to display the clean area rather than the whole picture.
! The top-left corner of the clean area has coordinates
! [(LeftOffset,TopOffset)]
! counting from the top-left corner of the picture data,
and
! dimensions $CleanWidth$ by $CleanHeight$.
! Note that these dimensions refer to pixels within a
picture, not a frame,
! so a change from interlaced to progressive picture coding
will
! necessitate a change of clean area if a custom clean area
is used.
! The clean area and the pixel aspect ratio together
determine the
! aspect ratio of the displayed image which is the ratio of
the width of the intended
! display area to the height of the intended display area:
!
[dfrac{CleanWidth*AspectRatioNumerator}{CleanHeight*As
pectRatioDenominator}]
!
! Given two separate sequences, with identical image aspect
ratio, if the
top left corner and bottom right corners of their clean
apertures are
coincident when displayed, then the images as a whole
should be exactly
***************
*** 316,320 ****
together appropriately if they are appropriately scaled.
-
The defined pixel aspect ratios are designed to give
standard image
aspect ratios for typical TV broadcasts. For example, for
a 525 line
--- 323,326 ----
***************
*** 322,332 ****
(704 x 10)/(480 x 11) which is exactly 4:3.
!
! For 625 line systems the 59:54 pixel aspect ratio means
(less
! conveniently) that a 702.9x576 image would have an exact
4:3 image
aspect ratio. It might be argued that the pixel aspect
ratio for 625
line systems should be such that a 702x576 image would
have an exact 4:3
! image aspect ratio. It could be said that this corresponds
to the
! analogue 625 line TV specification. This requirement would
lead to a
pixel aspect ratio of 128:117. However, the tolerance of
the analogue
line length is $702pm 3$ pixels, which does not really
seem to justify a
--- 328,337 ----
(704 x 10)/(480 x 11) which is exactly 4:3.
! For 625 line systems the 12:11 pixel aspect ratio means
(less
! conveniently) that a 704x576 image would have an exact 4:3
image
aspect ratio. It might be argued that the pixel aspect
ratio for 625
line systems should be such that a 702x576 image would
have an exact 4:3
! image aspect ratio, corresponding to the nominal sample
rate for 625 line TV.
! This requirement would lead to a
pixel aspect ratio of 128:117. However, the tolerance of
the analogue
line length is $702pm 3$ pixels, which does not really
seem to justify a
***************
*** 340,345 ****
standard' sampling frequencies are 11+3/11 MHz for 525
line systems
and 14.75MHz for 625 line systems. The ratio of these
frequencies to the
! (standardised) 13.5MHz sampling frequency used for
broadcasting yields
! the pixel aspect ratios given in and .
You are strongly advised to use one of the default pixel
aspect ratios.
--- 345,350 ----
standard' sampling frequencies are 11+3/11 MHz for 525
line systems
and 14.75MHz for 625 line systems. The ratio of these
frequencies to the
! (standardised) 13.5MHz sampling frequency used for
broadcasting (approximately)
! yields the pixel aspect ratios given.
You are strongly advised to use one of the default pixel
aspect ratios.
***************
*** 349,355 ****
unsuitable values.
-
end{informative*}
! subsection{Source parameter
presets}input
--- 354,517 ----
unsuitable values.
end{informative*}
!
! subsection{Source parameter presets}
! label
!
! Source parameters are signalled using a range of preset
indices into the following
! tables, as specified in Section ref.
Their correct
! interpretation by a display device is described in
Appendix ref.
!
! begin[!ht]
! centering
! begin{|c|c|c|}
! hline
! $index$ & $SFrameRateNumerator$ &
$SFrameRateDenominator$ \
! hline
! 1 & 24000 & 1001 \
! hline
! 2 & 24 & 1 \
! hline
! 3 & 25 & 1 \
! hline
! 4 & 30000 & 1001 \
! hline
! 5 & 30 & 1 \
! hline
! 6 & 50 & 1 \
! hline
! 7 & 60000 & 1001 \
! hline
! 8 & 60 & 1 \
! hline
! end
! caption{Available preset frame rate
values}label{table:frameratevalues}
! end
!
! begin[!ht]
! centering
! begin{|c|c|c|}
! hline
! $index$ & $SAspectRatioNumerator$ &
$SAspectRatioDenominator$ \
! hline
! 1 (Square Pixels) & 1 & 1 \
! hline
! 2 (525-line systems) & 10 & 11 \
! hline
! 3 (625-line systems) & 12 & 11 \
! hline
! end
! caption{Available preset aspect ratio
values}label{table:aspectratiovalues}
! end
!
! begin[!ht]
! centering
! begin{|c|c|c|}
! hline
! $index$ & $SLumaOffset$ & $SLumaExcursion$ \
! hline
! 1 (8 Bit Full Range) & 0 & 255 \
! hline
! 2 (8 Bit Video) & 16 & 235 \
! hline
! 3 (10 Bit Video) & 64 & 876 \
! hline
! end
! caption{Luma signal range available
presets}label{table:lumasignalrangevalues}
! end
!
! begin[!ht]
! centering
! begin{|c|c|c|}
! hline
! $index$ & $SChromaOffset$ & $SChromaExcursion$
\
! hline
! 1 (8 Bit Full Range) & 128 & 255 \
! hline
! 2 (8 Bit Video) & 128 & 224 \
! hline
! 3 (10 Bit Video) & 512 & 896 \
! hline
! end
! caption{Chroma signal range available
presets}label{table:chromasignalrangevalues}
! end
!
! begin
! The only presets available cover a full 8-bit range or 8-
or 10-bit SDI video ranges.
! If other video depths have been selected, custom signal
range parameters
! should be signalled, or the resulting video may have an
unintended appearance that
! affects video quality adversely on a display device.
! end
!
! begin[!ht]
! centering
! begin{|c|c|l|l|l|}
! hline
! $index$ & {bf Description} & {bf
Primaries} & {bf Matrix} & {bf Transfer
function}\
! hline
! 0 & Custom, HDTV, PC & Internet & 0 - ITU709
& sRGB & 0 - HDTV/PC & 0 - TV \
! hline
! 1 & NTSC & 1 -
SMPTE C & 1 - SDTV & 0 - TV \
! hline
! 2 & PAL & 2
- EBU Tech 3213 & 1 - SDTV & 0 - TV \
! hline
! 3 & D-Cinema & 3 -
CIE XYZ & 2 - YCoCg & 3 - DCI \
! hline
! end
! caption{Colour specification
presets}label{table:colourspecvalues}
! end
!
! begin[!ht]
! centering
! begin{|c|l|}
! hline
! $index$ & {bf Primaries} \
! hline
! 0 & ITU709 & sRGB \
! hline
! 1 & SMPTE C (as used for NTSC) \
! hline
! 2 & EBU Tech 3213, as used for PAL \
! hline
! 3 & CIE XYZ \
! hline
! end
! caption{Colour primaries
presets}label{table:primariesvalues}
! end
!
! begin[!ht]
! centering
! begin{|c|l|}
! hline
! $index$ & {bf Matrix}\
! hline
! 0 & HDTV, PC & Internet: $K_R=0.2126$,
$K_B=0.0722$ \
! hline
! 1 & SDTV: $K_R=0.299$, $K_B=0.114$ \
! hline
! 2 & Reversible: YCgCo \
! hline
! end
! caption{Colour matrix presets}label{table:matrixvalues}
! end
!
! begin[!ht]
! centering
! begin{|c|l|}
! hline
! $index$ & {bf Transfer function}\
! hline
! 0 & TV \
! hline
! 1 & Extended Gamut \
! hline
! 2 & Linear\
! hline
! 3 & DCI Gamma\
! hline
! end
! caption{Transfer function
presets}label{table:transfervalues}
! end
!
Index: state-macros.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/state-macros.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** state-macros.tex 23 Apr 2007 14:52:01 -0000 1.19
--- state-macros.tex 24 Apr 2007 09:35:00 -0000 1.20
***************
*** 100,105 ****
kdefine
kdefine
! kdefine
! kdefine
kdefine
--- 100,105 ----
kdefine
kdefine
! kdefine
! kdefine
kdefine
------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Dirac-commits mailing list
Dirac-commits lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dirac-com
mits
|