Then we're exactly on the same page! :-)
On 2/13/06, Andy Jones <andy(at)thefront.com> wrote:
> Sorry if I sounded harsh. I just wanted it to be clear, since the thread
> was sending mixed messages on a primarily technical matter. In a
> non-technical sense, you're right -- conceptually, it's very useful to think
> of decimals instead of integer values even if you're using 8 or 16-bits. So
> useful in fact, that I get annoyed every time I see colors encoded on a
> 0-255 scale. I guess it really comes down to the difference between the
> phrase "floating point" and the data type "float". For example, in a
> hypothetical plea to Softimage, I might say, "Can you please, for the love
> of god, make the 'scene colors' palette use a floating point representation
> instead of an 8-bit integer representation?" In that case, I'm really just
> asking to see the value .5 instead of 127, and I probably don't really care
> what data type they choose, since it's just the background color and I
> probably don't need a lot of extra precision or values beyond 1.0. Because
> of this confusion, I think it's useful to refer to these decimal
> representations of integers as "normalized values" instead of floating point
> values. In general, normalization means redistributing values into a
> different range. A very common type of normalization is division by a
> maximum value (in the case of 8-bit colors, 255) so that the maximum in the
> resulting range is 1.0.
>
> -Andy
>
> On 2/12/06, Halfdan Ingvarsson <hingvars(at)softimage.com> wrote:
> >
> >
> > That doesn't make it any less wrong ;-)
> >
> > Contrary to your original mail, the nice thing about floating point
> numbers in images is that you're not restricted to the 0 - 1 value range.
> >
> > So it's not the gain in precision that is the desireable property of
> floating point numbers, it is the gain in dynamic range.
> >
> > The 50% improvement in precision over 16-bit images is a nice side-effect,
> especially when comping with a silly number of layers. The greatest benefit
> is being able to introduce the same ultra-high dynamic range as found in
> nature in your computer generated imagery, and hence adding greatly to the
> realism of the result.
> >
> > - ½
> >
> > ________________________________
> From: owner-xsi(at)Softimage.COM on behalf of Arvid Björn
> > Sent: Sun 12-Feb-06 14:32
> > To: XSI(at)Softimage.COM
> > Subject: Re: embarrasingly stupid question
> >
> >
> >
> >
> > Using the word "wrong" is a little harsh. It's a very useful way to
> > look at computer graphics, having coded both OpenGL applications and
> > image processing applications, I'd say it's a fundamental concept to
> > computer graphics. Halfdan's was scientific and probably
> > mathematically correct tho, but a little less applicable to using
> > floats with XSI, IMO, however I'm not an engineer.
> >
> >
> > --
> > stockholm.postproduction | www.stopost.se
> >
> >
> > On 2/10/06, Andy Jones < andy(at)thefront.com> wrote:
> > > There are some right answers and some wrong answers here. Halfdan's
> > > answer is right. Arvid's is wrong. Greg's is wrong. While it's true
> > > that a 32-bit floating point value has 2^32 possible values, it's not
> > > correct to think of these values as shades of grey between 0 and 1.
> > > That would be more like a 32-bit integer which also exists, but isn't
> > > typically used in computer graphics. The purpose of a floating point
> > > representation is to store values in a much wider range than 0 to 1.
> > > For example, the position data for vertices in your scenes is stored in
> > > a floating point representation. Floating point numbers are typically
> > > represented with the 32-bit "float" type or the 64-bit "double" type.
> > > For images, there is also a 16-bit floating point type being popularized
> > > for image data via OpenEXR and graphics hardware. This type is called
> > > "half," presumably in honor of Halfdan Ingvarsson. It's useful because
> > > for images, we're typically working in a range larger than [0,1], but
> > > not as big as what we need with general purpose floating point data
> > > types. And the level of precision required is less because the levels
> > > stored are pretty much always approximated anyway.
> > >
> > > There are many reasons you might choose a floating point representation
> > > for your image data. Greg is correct that 16 bit integer precision
> > > typically alleviates banding problems that arise when doing standard 0-1
> > > compositing operations, like what you do in a typical AfterEffects <7.0
> > > workflow. In fact, 8 bits is basically enough to encode images for
> > > viewing, once no additional color space modifactions are to be made.
> > > That's why the output buffers in computer graphics cards have pretty
> > > much stuck at 8 bits per channel (remember when there were fewer?). The
> > > eye can't typically differentiate the shades of gray beyond 8 bits or
> > > 256 shades. Maybe one or two more bits wouldn't kill us, but 16 is way
> > > more than enough and is needed only if parts of the range are going to
> > > be stretched.
> > >
> > > As it concerns the linear workflow we've been talking about, floating
> > > point representation is useful because instead of attempting to render
> > > image data that is ready for viewing on a computer monitor (and
> > > therefore will be clipped to [0,1] anyway, we're attempting to store
> > > relative amounts of light which don't have to stop at 1. Once we have
> > > the images representing amounts of light, we can perform operations such
> > > as exposure and gamma correction to prepare the data for viewing on a
> > > computer monitor. At that point, the data can be clipped to [0,1] and
> > > integer representations are useful again. In general, output formats
> > > can be a lot more restrictive in terms of range and precision than
> > > intermediate data that's going to be modified in some way. That's why
> > > while 10-bit Cineon has been great for film plates and you can't really
> > > tell what's been digitized to cineon and reprinted, there is still a
> > > push in the film industry to use formats like OpenEXR for storing frame
> > > data.
> > >
> > > It's really all about representing data with consistent precision levels
> > > inside and outside of a [0,1] range.
> > >
> > > -Andy
> > >
> > > Sylvain Moreau wrote:
> > >
> > > > >>>So isn't there a limit to how many colors we can actually
> > > > perceive? I'm not sure if my eyes are 32-bit compliant.
> > > >
> > > > Good question, here is part of the answer:
> > > >
> > > > - An average person can perceive around 100 000 colors. Trained
> > > > professional can see between 200 000 to 300 000.
> > > > - One man out of eleven has some sort of color blindness and actually
> > > > sees a lot less than 100 000 colors (color blindness is very rare
> > > > among women)
> > > > - 8 bits RGB gives you more than 16 000 000 colors but this is not
> > > > enough because computers use linear interpolation and your eye
> > > > perception is not linear (the eye sees a lot of subtle changes in the
> > > > dark but very little in the bright area)
> > > > - 16 bits is enough. My take on this is your eye will stop perceiving
> > > > changes between colors somewhere in the 10 to 12 bits range.
> > > > - 32 bits is overkill but still very useful in some situations (e.g.
> > > > heavy color correction, hdr, etc.)
> > > >
> > > > syl
> > > > ~~~~~~~~~
> > > > wotomoro.com
> > > >
> > > > ----- Original Message -----
> > > > *From:* Meng-Yang Lu <mailto:ntmonkey(at)gmail.com>
> > > > *To:* XSI(at)Softimage.COM < mailto:XSI(at)Softimage.COM>
> > > > *Sent:* Friday, February 10, 2006 2:29 PM
> > > > *Subject:* Re: embarrasingly stupid question
> > > >
> > > > So isn't there a limit to how many colors we can actually
> > > > perceive? I'm not sure if my eyes are 32-bit compliant.
> > > >
> >
> > > > -Lu
> > > >
> > > >
> > > > On 2/10/06, *Todd Akita* <takita(at)earthlink.net
> > > > < mailto:takita(at)earthlink.net>> wrote:
> > > >
> > > > Man, that is a LOT of crayons.
> > > >
> > > > -T
> > > >
> > > > Greg Smith wrote:
> > > >
> > > > > a floating point digital image is a 32-bit image. with
> > > > 8-bit images
> > > > > each RGB channel has 256 levels of value, a 16 bit image has
> > > > 65,536
> > > > > levels of value per channel and a floating point, or 32 bit
> > > > image has
> > > > > 4,294,967,296 levels of value per channel. take that number
> > > > to the
> > > > > power of 3 and you get how many possible colors you get in
> > > > RGB space,
> > > > > which is a lot of color.
> > > > >
> > > > > Greg
> > > >
> > > >
> > > >
> > > > ---
> > > > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > > > <mailto:Majordomo(at)Softimage.COM>with the following text in
> body:
> > > > unsubscribe xsi
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> > > unsubscribe xsi
> > >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > unsubscribe xsi
> >
> >
> >
>
>
--
stockholm.postproduction | www.stopost.se
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
