[opendtv] Re: News: High Dynamic Range imaging

  • From: Tom Barry <trbarry@xxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Mon, 07 Aug 2006 07:26:03 -0400

Back when I was playing with stock market algorithms I would create a 
distribution simply by sorting a history of all the daily percentage 
changes in order and then applying percentiles (or finer) to them.  This 
distribution could typically be approximated fairly well with only 2-4 
parameters using a wide tailed slight slightly skewed log normal 
distribution.

At the time I was using it to calculate (one view of) option values but 
I suspect if we sorted all the pixel values in any given frame we'd find 
  something similar for most cases. I'd bet 8 bit pixels representing 
points on some modeled distribution like that could represent a lot of 
information.

- Tom



Jeroen Stessen wrote:
> Hello ! 
> Tom Barry wrote:
> 
>>>I've wondered for some time now if it would be better to
>>>use some non-fixed color space where that S-curve, log
>>>curve, or whatever was parametrically defined for each
>>>frame, based upon the probability distribution of the actual
>>>values needed.  The actual values used for each frame
>>>would be determined at the time of down converting from
>>>some higher bit space, say in the camera or telecine
>>>machine.
> 
> 
> That's exactly what I once proposed to Prin, after his 
> presentation on Digital Cinema. My exact words: At the end of 
> the day a gamma function is just a quantisation table. 
> There is no reason to choose a fixed function and then waste 
> many quantisation codes on values that are never used. You need 
> the low values for the dark scenes and the high values for the 
> bright scenes, but not at the same time. 
> 
> I hope that nobody is suggesting that we use HDR displays 
> (like BrightSide's) for entertainment purposes ? 
> See: http://www.brightsidetech.com/
> 
> Because my non-HDR eyes will protest ! Dust in my eyeballs, dust on 
> the projection optics, dust in the theater, and any other causes of 
> flare, they will all cause the black level to be raised to dark grey 
> and all details to be lost. There is no point in trying to render deep 
> blacks if they never reach your retina. Better to compress the dynamic 
> range to between 1000:1 and 100:1 and preserve at least the details 
> in the blacks. For example with an algorithm like Nasa's Retinex: 
>   http://dragon.larc.nasa.gov/
> 
> It is okay to capture data in HDR, but it's not okay to present it 
> in that form to the human eyes. It will be like driving with the 
> sun in your face and a dirty windshield. Not a pleasure ! 
> 
> 
> Bert Manfredi wrote: 
> 
>>What seems to be missing from this thread is that the 8 or 12 or 
> 
> whatever 
> 
>>bits used to quantize the light samples are not linear with intensity, 
>>right? I mean, in practice (although they could be made linear, I 
> 
> suppose.) 
> 
>>As intensity increases, the coarseness of quantization increases by some 
> 
> 
>>power factor -- Gamma correction. So things aren't quite as bad as 
> 
> linear 
> 
>>coding.
> 
> 
> Exactly. Gamma functions are used for video, and log curves sometimes 
> for professional applications. This is necessary for not wasting too 
> many codes on shades of white that can not be distinguised anyway. 
> 
> But it is still wasteful... You need more bits for coding variations 
> between scenes than for variations within a scene. Going to 12 or 
> more bits just because in a dark cinema you can better distinguish 
> details in the dark scenes is wasteful. If there were a bright object 
> in the same scene then you could not look in the dark anymore, so you 
> could give some coding values to white and take them away from the 
> blacks. 
> 
> So this obviously calls for a dynamic coding, a variable range. 
> I would like to take the concept of "perceptual coding" one step 
> further, and include the dynamic adaptation of the eye... 
> 
> 
>>Doesn't ATSC use some gamma correction defined in ITU-R BT 709? 
> 
> 
> Officially yes. Unofficially they will use whatever correction is 
> necessary to make the picture look good on the studio monitor... 
> 
> 
>>Charles Poynton sez that if you do gamma correction before quantizing, 
>>even 8 bits per sample are actually okay. 
> 
> 
> That is only very conditionally true ! Three major conditions: 
> - you need a typical viewing ambient, not too dark, and 
> - you need some analog noise on the signal before quantisation, and 
> - you can't do any cascaded operations on the 8-bits signals ! 
> (Operations of the type that introduce more quantisation noise.) 
> 
> If you had a digitally rendered signal and quantize it to 8-bits 
> on a Rec.709 gamma function and then view it in a dark cinema, I 
> am certain that the quantisation of the blacks will look terrible. 
> The toe gain of 4.5 is way way too low for preserving the blacks. 
> 
> 8-bits D1 was good for taping noisy analog video signals, it is 
> not enough for a complete digital video chain. 
> 
> 
>>That whole presentation is pretty interesting. He says that linear 
>>8 bit quantization is not nearly enough.
> 
> 
> That is very true, however, his "nemesis" Timo Autiokari also 
> makes a good point of why the gamma domain should not be used for 
> some (many ?) types of signal processing: 
> http://www.aim-dtp.net/aim/evaluation/gamma_error/index.htm
> 
> Did you know that Charles is fully employed these days ? 
> 
> Best, 
> -- Jeroen
> 
> +-------------------------------+------------------------------------------+
> | From:     Jeroen H. Stessen   | E-mail:  Jeroen.Stessen@xxxxxxxxxxx |
> | Building: SFJ-5.22 Eindhoven  | Deptmt.: Philips Applied Technologies |
> | Phone:    ++31.40.2732739     | Visiting & mail address: Glaslaan 2 |
> | Mobile:   ++31.6.44680021     | NL 5616 LW Eindhoven, the Netherlands |
> | Skype:  callto:jeroen.stessen | Website: http://www.apptech.philips.com/ 
> |
> +-------------------------------+------------------------------------------+
> 
> 
>  
>  
> ----------------------------------------------------------------------
> You can UNSUBSCRIBE from the OpenDTV list in two ways:
> 
> - Using the UNSUBSCRIBE command in your user configuration settings at 
> FreeLists.org 
> 
> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
> unsubscribe in the subject line.
> 
> 
 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: