Re: [Gimp-developer] Hey

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Erm, dunno why this didnt reply to the list.
To those who missed stuff, I asked "Is it easy to add 16-bit per channel
support to gimp?" the answer was "No it isnt."

But yeah, Film Gimp has issues. The xcf loader plugin doesnt work at all on
x86 (known bug) so thats why I turned back to Gimp to see if I could get it
here. (I do all my graphics artwork in Gimp.)

This might sound a little dumbassish on my part, but why wasnt 16-bit support
added earlier? As far as I know, even Photoshop 6 doesnt have this (and when
in native 16-bit mode, I cant get it to do layers at all.) And, yes, its hard   
to do now, but it wouldnt have been as hard in gimp 1.1 when it was in heavy
development mode. Now of course, this would force all gimp 1.0 plugins to break
(assuming the majority didnt already.) 

Though, my method wouldnt break any plugins, however. Any plugin accessing the
data would get back 8bit values because the layers are still in 8bit mode, its
only a higher precision rendering engine that would be added. 8 bit goes in,
8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+
layers, all doing things other than Normal mode, and sometimes bringing the
darkest color below 0,0,0, and the lightest color above 255,255,255, it comes
in handy.)

On 11-Nov-2002, Raphaël Quinet wrote:
> On Mon, 11 Nov 2002 05:44:52 -0500, Patrick McFarland <unknown@xxxxxxxxx> wrote:
> > Hmm, that todo is pretty cool. But Is there any way to push 16-bit rendering
> > earlier? Or is there any other sane way to do this?
> 
> The easiest way to push the 16-bit rendering earlier is to write the code and
> submit it to the developers.  Alternatively, if you cannot program yourself,
> you could try sponsoring someone.
> 
> If you are only interested in getting 16-bit support but you do not care about
> all plug-ins and new tools that were introduced since GIMP-1.0, then you can
> try http://film.gimp.org/ or http://filmgimp.sourceforge.net/.  This will give
> you the 16-bit rendering that you are looking for, but this version of the
> GIMP has slightly older tools and less plug-ins than the ones you get in the
> current stable version of the GIMP. 
> 
> > I dont know how the rendering pipeline works, but wouldnt it be relitivly easy
> > to switch all the 8 bit variables with 16 bit ones, and just cut the final
> > down to 8 bit for display, plugin data reading, and layer flattening?
> 
> No, it is not so easy.  There is a lot more to be done than that: with 8 bits
> per channel, the RGBA pixels (R, G, B + Alpha) can be stored in a 32-bits 
> integer ("int" or "long" in C) and this is done in many places in the core of
> the GIMP as well as in the plug-ins.  With 16 bits per channel, this would 
> require a 64-bit integer, which is not available natively on many platforms.
> So a lot of code has to be re-designed.  In addition, many parts of the code
> for calculating pixel coordinates and other things (mapping the coordinates to
> the position of the data in memory) would have to be changed.  Even if the
> changes are not always big, there are still several thousands of lines of code
> that have to be changed.
> 
> -Raphaël
> 
> P.S.: You sent your reply directly to me.  You could have sent it to the list
>       as well, because I assume that some other people could be interested.


-- 
Patrick "Diablo-D3" McFarland || unknown@xxxxxxxxx
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux