Return-Path: Received: from mail-yw0-f41.google.com ([209.85.213.41] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 4721835 for AE-List@media-motion.tv; Tue, 22 May 2012 18:03:50 +0200 Received: by yhr47 with SMTP id 47so5783929yhr.28 for ; Tue, 22 May 2012 09:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TXVDGnIIxQ3BO9kYvVxO/UzQ8wjSnmVVhQDXl/hgek8=; b=ZshvQojiIbsc1NFhhe8Izqw7u8R1MVj5iL6x7rJ36VrYrV1F+IclanCxbS6jfodk+U qS+qXWAs96HifgpfMej6jBEvVsrCD2XBQfRL6GK3rk1uTIGQm/JyLnSrL8tA8n5IPBXR l6JrJmkXSHd98DzGWzeYE/G6/PdCaPXg7W4l/kZ3+zf9t9JYG8Ij4r6lMuk7NX99tIgq VIhdDaaY6QR7Szk8yKcKupvSQcCwpwmmKiLr3O5a7pPx/geTSvCXzw8+c6mwDGHTlDs0 i/5/QXVASFrQNfeu2jQXozlTNBHwrZI8eCnD+GYy42bEaUt6jE18djrgvFdBaRc7IDIF CdJw== MIME-Version: 1.0 Received: by 10.68.229.65 with SMTP id so1mr286942pbc.2.1337702749113; Tue, 22 May 2012 09:05:49 -0700 (PDT) Received: by 10.143.61.17 with HTTP; Tue, 22 May 2012 09:05:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 18:05:49 +0200 Message-ID: Subject: Re: thx for responding to gradient question From: Py Fave To: After Effects Mail List Content-Type: multipart/alternative; boundary=047d7b162e7b2d0ce304c0a231b0 --047d7b162e7b2d0ce304c0a231b0 Content-Type: text/plain; charset=ISO-8859-1 definitive reply ! The Blu-ray specification does not support video encoded with either deep color or xvYCC; http://en.wikipedia.org/wiki/HDMI#endnote_bdF http://en.wikipedia.org/wiki/Deep_color#Deep_color_.2830.2F36.2F48-bit.29 you have to use a computer ,hdmi 1.3 minimum if hdmi, if you see some hard disk or ssd player supporting 16 bits,please tell it to this list. please reply to the list have a nice day Py 2012/5/22 Sixtus Beckmesser > I can't use noise since it introduces an uncertainty as to precisely what > the pixel value is at any point on the screen, which is contrary to the > purpose of an analytical test pattern. The pattern I sent you is intended > for visual inspection -- any skipped or repeated values in Y will instantly > be visible as an increase of banding, which you can easily see by trying to > encode it directly though any YUV encoder. The pattern is designed to sniff > out any increased banding imposed by the TV set it is played on, which is > why I can't have any skipped or repeated values in the original. For > Blu-ray, one is stuck with 8-bit encoding for signals on the disc, which is > why I need a way to convert one channel of an RGB signal directly into a Y > signal, without any recalculation, just move the selected channel's data > into the Y channel. If I knew the precise file format of, say, an 4:2:2 YUV > AVI signal, I would do it manually -- by writing a program that puts Y U > and V pixel data directly into an artificially created file. But I've had > trouble finding a suitably detailed description of that file format and it > would be my last resort, due to the length of time it would take to write > the software. > > D > > > On Tue, May 22, 2012 at 4:47 AM, Py Fave wrote: > >> lets keep this on the list. i am curious of other people's responses >> >> as i see it ,the problem is in the media. >> if you can't display more than 8 bit colors , >> you're stuck. >> >> professional systems use SDI connexions on expensive monitors mostly to >> get these things solved. >> i don't know exactly in video , but in (digital) cinema , you can keep >> your image 16 bits on screen . >> (dpx or tiff support this, f. i.) >> >> >> anyway , if it is for color calibration, don't consider that the probe >> will be aligned on a pixel . >> it will give a median value from surrounding pixels , this will smooth >> out your values . >> >> and if you use the "noise" trick (in fact it is called stochastic >> distribution or something like this :-) >> it will give pretty good values. >> >> if you HAVE to output bluray , it will be 8 bits. >> >> 16 bits is not affordable for consumer market now . >> tell me if i'm wrong please . >> >> "I'd be eternally grateful." hehe >> have a nice day >> >> >> >> Thanks for responding to my query about gradients. You're the first one >>> to do so. >>> >>> The MPEG-4 encoders for all Blu-ray require 8-bit video in YUV form, >>> which is one of the primary faults of the system. Using ten bit RGB as >>> input to an 8-bit YUV format won't help matters if the results are still >>> rounded off to 8 bits with the same round-off errors as with 8-bit >>> originals. >>> >>> I realize adding noise will smooth gradients, but these are test >>> patterns where I need the Blu-ray players to produce the PRECISE values I >>> intend so as to test the gradient response of the SCREENS! >>> >>> Attached is the file I've been trying to encode without success. Note on >>> the horizontal axis every pixel value between 16 and 235 appears for >>> precisely the same amount of time (except for some stuff going on near the >>> left edge). With every encoding procedure I've tried, either some pixel >>> values are repeated or are repeated, with consequent increased banding on >>> playback. >>> >>> Thx again for your attention and if you can figure out how to do this >>> I'd be eternally grateful. >>> >>> David >>> >> >> > --047d7b162e7b2d0ce304c0a231b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable definitive reply !

The Blu-ray specification does not support video= encoded with either deep color or xvYCC;

http://en.wikipedia.org/wiki/HDMI#endnote_= bdF

http://en.wikipedia.org/wiki/Deep_color#Deep_color_.2830.2F3= 6.2F48-bit.29

you have to use a computer ,hdmi 1.3 minimum if hd= mi,

if you see some hard disk or ssd player supporting 16 bits,please tell = it to this list.
please reply to the list

have a nice day
Py


2012/5/22 Sixtus Beckmesser <sbeckmesser@gmail.com>
I can't use noise since it introduces an= uncertainty as to precisely what the pixel value is at any point on the sc= reen, which is contrary to the purpose of an analytical test pattern. The p= attern I sent you is intended for visual inspection -- any skipped or repea= ted values in Y will instantly be visible as an increase of banding, which = you can easily see by trying to encode it directly though any YUV encoder. = The pattern is designed to sniff out any increased banding imposed by the T= V set it is played on, which is why I can't have any skipped or repeate= d values in the original. For Blu-ray, one is stuck with 8-bit encoding for= signals on the disc, which is why I need a way to convert one channel of a= n RGB signal directly into a Y signal, without any recalculation, just move= the selected channel's data into the Y channel. If I knew the precise = file format of, say, an 4:2:2 YUV AVI signal, I would do it manually -- by = writing a program that puts Y U and V pixel data directly into an artificia= lly created file. But I've had trouble finding a suitably detailed desc= ription of that file format and it would be my last resort, due to the leng= th of time it would take to write the software.

D=A0


On Tue, May 22, 2012 at 4:47 AM, Py Fave <pyfave@gmail.com>= wrote:
lets keep this on the list. i am curious of other people's responses
as i see it ,the problem is in the media.
if you can't display = more than 8 bit colors=A0 ,
you're stuck.

professional system= s use SDI connexions on expensive monitors mostly to get these things=A0 so= lved.
i don't know exactly in video , but in (digital) cinema , you can keep = your image 16 bits on screen .
(dpx or tiff support this, f. i.)

=
anyway , if it is for color calibration, don't consider that the pr= obe will be aligned on a pixel .
it will give a median value from surrounding pixels , this will smooth out = your values .

and if you use the "noise" trick (in fact it= is called stochastic distribution or something like this :-)
it will gi= ve pretty good values.

if you HAVE to output bluray , it will be 8 bits.

16 bits is not= affordable=A0 for consumer market=A0 now .
tell me if i'm wrong ple= ase .

"I'd be eternally grateful." hehe
have a ni= ce day



Tha= nks for responding to my query about gradients. You're the first one to= do so.

The MPEG-4 encoders for all Blu-ray require 8-bit video in Y= UV form, which is one of the primary faults of the system. Using ten bit RG= B as input to an 8-bit YUV format won't help matters if the results are= still rounded off to 8 bits with the same round-off errors as with 8-bit o= riginals.

I realize adding noise will smooth gradients, but these are = test patterns where I need the Blu-ray players to produce the PRECISE value= s I intend so as to test the gradient response of the SCREENS!=A0

Attached is the file I've been trying to encode without = success. Note on the horizontal axis every pixel value between 16 and 235 a= ppears for precisely the same amount of time (except for some stuff going o= n near the left edge). With every encoding procedure I've tried, either= some pixel values are repeated or are repeated, with consequent increased = banding on playback.

Thx again for your attention and if you can figure out = how to do this I'd be eternally grateful.

Davi= d



--047d7b162e7b2d0ce304c0a231b0--