[Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit

[Leonard Rosenthol]

At 6:27 PM +0100 11/1/02, Guillermo S. Romero / Familia Romero wrote:

PNG should be included in this family too, BTW. Any other format?


	TIFF and PSD also support 16bit data...


Leonard
--
---
Leonard Rosenthol
 			 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit

[Nathan Carl Summers]

On Fri, 1 Nov 2002, Guillermo S. Romero / Familia Romero wrote:
> I think it should be visual, a window with the image in 8 bit, and
> controls that decide how to get that 8 bit from the original 16 or 32.
> Basically black & white points and a curve. I say visual, cos it could
> mean what one does in the lab, but digital (load some copies, adjust
> each one at will, and mask and mix all the copies to get the final
> image).

Would error-diffusing dithering be an option people would like?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit

[Guillermo S. Romero / Familia Romero]

[EMAIL PROTECTED] (2002-11-01 at 0136.10 +0100):
> Just FYI (I have no specific goal with this mail ;): I met some guy from
> Dreamworks ("Shrek") at the LWE in Frankfurt, and he told me that their
> whole rendering infrastructure is 8 bit, including intermediate results
> (so the whole of Shrek was done at 8 bits, with a later dynamic adjustment
> of the results into the necessary range).

I guess they work with linear data all the way. Just mainly cos I have
been trying some tricks with a 3D app, and they went boom until I told
the app to stop using gamma.

> And finally he told me that the need for 16 bit and floating point is
> there in many but not most cases, so one _can_ get along without it, at
> leats for rendered scenes.

But not for real and render at the same time, and not for bad tuned
render either. I am reading and getting info about this, seems linear
and high range is best, if not, you have to choose how do you damage,
but you hardly avoid it. Cineon is 10 bit and non linear, digital
photo cameras start to give RAW dumps with more than 8 bit, some
places use 32 bit float already (I would have say Dreamworks would
have too... or at least 16 int)...

Why all this rant? The more info, the better, I am trying to write
about all this, so users know what GIMP can do, and how to solve the
problems (or get the less noticeable error), and coders can get info
about desired usage.

GSR
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit

[Guillermo S. Romero / Familia Romero]

[EMAIL PROTECTED] (2002-11-01 at 0211.09 +0100):
> adjustments before the data is propagated down to 8bit? I was thinking
> of something like the levels tool. Do you think it would be possible
> to perform a reasonable first color adjustment only by looking at a
> histogram? In that case it should relatively easy to add that

It could be, yes, but I do not think a pure math way is the right way,
images are "more white, no, less, tweak that".

> functionality to some of the file plug-ins. Since this wouldn't need
> any support from the GIMP core (albeit perhaps some helper functions
> in libgimp and libgimpwidgets) this could happen for GIMP-1.4. What do
> you think?

I think it should be visual, a window with the image in 8 bit, and
controls that decide how to get that 8 bit from the original 16 or 32.
Basically black & white points and a curve. I say visual, cos it could
mean what one does in the lab, but digital (load some copies, adjust
each one at will, and mask and mix all the copies to get the final
image).

PNG should be included in this family too, BTW. Any other format?

GSR
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer