Sven Neumann wrote:
we are aware of the need and will turn to it as soon as 1.4 is out of
the door. Until then, here's an idea that would probably help: What if
we improve the file plug-ins that read file types that support higher
color depths (like TIFF) in such a way that they allow to do
Hi,
David Hodson [EMAIL PROTECTED] writes:
What if
we improve the file plug-ins that read file types that support higher
color depths (like TIFF) in such a way that they allow to do simple
adjustments before the data is propagated down to 8bit?
My Cineon/DPX plugin does exactly this.
On another note about 16 bits, I've been thinking about writing a
standalone version of the Print plugin that could interactively print
a file outside of the GIMP. I had this in mind more for Macintosh OS
X, but would this be of more general use?
--
Robert Krawitz
That might not be a bad interim solution. My workflow goes something
like this:
Scan with little to no adjustments
Level correct, possible minor overall color correct
Convert to 8 bit
Create dodge/burn masks etc.
Sharpen
Output
So I could do most of my 16 bit work with a histogram. Of course I
On Fri, 1 Nov 2002, Marc wrote:
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,
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
Hi,
RW Hawkins [EMAIL PROTECTED] writes:
True, 8 bit is OK for animation work (like Shrek) but for live
action it just does not cut it. This is why film gimp supports 16
bit. Any house doing live action work is likely long switched over to
16 bit.
As a photographer my results are