Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
Hi, Stephen J Baker [EMAIL PROTECTED] writes: So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP. IMHO, that's a better route to take than going to 16 bit or even integer 32 bit. the plan is not to have 16 bit or 32 bit or floats but to offer a framework that allows to handle image data more or less independently of its representation. GEGL is the framework and it already supports floating point, 8bit and 16bit integer. Adding more data formats shouldn't a the major problem. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 10-Dec-2002, Sven Neumann wrote: the plan is not to have 16 bit or 32 bit or floats but to offer a framework that allows to handle image data more or less independently of its representation. GEGL is the framework and it already supports floating point, 8bit and 16bit integer. Adding more data formats shouldn't a the major problem. This is why I want film gimp to use gegl at its core, instead of the old gimp engine. Gimp and Film Gimp cant be limited in any way in the core of the program, so being able to support any bitdepth is extreamly important. Though, what needs to happen is that the internal rendering core, and all plugins need to support _atleast_ one major format, and that would be RGB/RGBA 32-bit float (aka spfp) per channel. Preferably, gegl would choose the best format (RGBA spfp for RGB, CYMK spfp for CYMK, and maybe a YUV spfp format? That could be useful for film gimp) for rendering and data transmission between modules/plugins. (It would choose the highest bitdepth option for the colorspace.) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] 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 msg03256/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On Fri, 29 Nov 2002, Sam Richards wrote: I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for High Dynamic Range imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future. I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 09-Dec-2002, Stephen J Baker wrote: On Fri, 29 Nov 2002, Sam Richards wrote: I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for High Dynamic Range imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future. I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once. Erm, thats kinda cool, but unless we can access that framebuffer, it wont be useful to us. We'll still be stuck writing to the 8bit per channel 2D framebuffer. (Now, of course, we could chop the final display image into GL texturers, and display that, but that requires a spfp per channel GL texture mode.) Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white ( 1.0) and below pure black ( 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.) This also helps with HDR too. HDR is a spfp per channel storage mode, used by several high end industry apps. Those included is Lightwave, the famous 3D modeling/rendering application. With HDR enabled (and saving in a HDR format), you can alter the final image to bring out more detail from shadows and such by just altering the gama ramp, Due to the huge ammount of data, you wouldnt notice the difference the fixed copy, and the entire image rerendered with new lighting settings to correct the mistake: the least significant bit of data is still below even 16-bit per channel display modes. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] 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 msg03243/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
On 09-Dec-2002, Stephen J Baker wrote: I'm not suggesting that this would be useful to GIMP - but that other developers who are working in 3D using modern rendering hardware will soon need support for 32 bit floating point texture maps. So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP. IMHO, that's a better route to take than going to 16 bit or even integer 32 bit. Im not saying Gimp3D here: Im just saying using GL as an advanced framebuffer. Unless X (or win32) itself supports the spfp bitdepths, then our only recourse would be to use GL textures as a framebuffer to display the image. Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white ( 1.0) and below pure black ( 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.) You could use a modern graphics pipeline for that too - but it's a lot less friendly to code for - and it won't port to all graphics cards - so it's probably not likely to be a thing that GIMP would want to make use of. On something like an ATI Radeon 9700 or the upcoming nVidia GeForceFX, you can create floating point texture maps - and use the incredibly fast 'fragment shader' processor to composite, scale, rotate, perspect, tile or otherwise process them into the floating point frame buffer, then read that back into the CPU at the end. Whether that's faster than doing it in the CPU alone depends on the complexity of the per-pixel processing - for complex per-pixel operations, I'd expect the graphics card to be able to beat the CPU - but for simple operations the data transfer overheads into and out of the graphics card would kill you. The nVidia card also supports a 16 bit 'half float' format which would be interesting for HDR. All of thats basically worthless to us _except_ for non-real preview modes where it doesnt matter if the image looks perfect, because its just an approximation. We cant use it for real rendering, because an xcf has to look the same on _all_ machines that view it. That means no matter what video card I have, it has to look the same on someone else's box, no matter what video card he/she has. The half float mode might be slightly useful for imitating a 16-bit per channel display. But that goes back to using gl textures as a framebuffer. There were a bunch of papers at SigGraph last year about rendering HDR images on a standard display without losing important visual information. All interesting stuff. That wouldnt make alot of sense. HDR isnt ment for displaying. Its ment for holding extra data that otherwise would be lost. For a final end target (eg png, jpg, dvd) the extra HDR data is thrown out because it is no longer needed. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] 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 msg03246/pgp0.pgp Description: PGP signature
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
Hi, Sam Richards [EMAIL PROTECTED] writes: I would like to know what the roadmap for gimp is after 1.4? When is the merge for GEGL? Are you planning 16 bit support as a separate thing to GEGL? Are there any design docs for 1.3? How much work was it porting to GTK2.0? This document is probably still valid in a lot of points: http://developer.gimp.org/gimp-future We will try to come up with something more uptodate soon. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [FilmGimp] Re: [Gimp-developer] Film Gimp and GIMP
Hi, I am one of the developers of filmgimp, although really I am mostly bug-fixing and packaging it at the moment. While I'm not going to comment on accuracies of the web site, thats Robins area, but I would like to address some of the other issues raised... Firstly, like everybody else, I would prefer to avoid the split in code, and cant wait for GEGL to make it into gimp.. However, I feel that filmgimp satifys a short term need which is for a 16 bit and floating point paint package, until the 2.0 release happens. I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for High Dynamic Range imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images. The next major reason for developing filmgimp is a time-frame issue, VFX houses are rapidly moving to linux as their primary platform, and one of the many missing apps is a basic paint system (such as matador), the hope is that we can develop filmgimp to that level in a short time frame (6 months). The issues that we are dealing with are: * More recognisable UI - which generally means make it more photoshop like. The issue here is that many of our artists will only need a paint system once in a while, so we need a UI that is familiar to them. * Improved brushes (over current filmgimp version). * Better layer and channel support, in-particular for alpha channels. These have been issues that we have had with gimp for quite a while, and I think its very interesting that RnH (the main filmgimp developers), have been slowly addressing these issues and that their goals are extremely similar to ours. I would like to believe that once 2.0 starts forming, that all of us start migrating over to that new code-base. While there has been much talk about merging the filmgimp version back into gimp (or even the other way around), the difference are extremely large, even more if we talk about 1.3, I also would prefer to see filmgimp as a short term solution and rather than spend quite a bit of time trying a merge, I would personally prefer to spend the time later on 2.0, since most of the work and fixes that we would be doing during the merge would need to be redone for 2.0. I would like to know what the roadmap for gimp is after 1.4? When is the merge for GEGL? Are you planning 16 bit support as a separate thing to GEGL? Are there any design docs for 1.3? How much work was it porting to GTK2.0? Anyway, I have just joined the gimp-developer list, and will try to be more actively envolved, so that hopefully later I can contribute more to 2.0 down the road. Thanks... Sam. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
