10 ms·

Cinepaint: The long forgotten GIMP fork that once powered the cinema industry

190 points by marcodiego 5y ago

mixmastamyk 5y ago
Unfortunately, there’s no info here about why it fell out of favor. Only up to the rename.
- rleigh 5y ago
  The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. Look at the difference between how different open-source projects operate. Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. It's kind of sad that the Cinepaint people got several paid staff to lift the GIMP functionality to the point it had very high-profile commercial use with some really useful features, and yet the GIMP developers were too stubborn to acknowledge this effort and work with them to get the functionality into the GIMP core. Sadly, this is not unique to the GIMP. I, and other commercial developers, had exactly the same experience with GTK+ and GNOME libraries. The developers wanted to hack on their pet thing, ignore outside contributions, and this is simply not compatible with commercial timelines and realities. But it can be, and it can work very well, for projects which are willing to engage with outside work. It can work out to be very mutually beneficial with some give and take on both sides. I was on the GIMP mailing lists at the time and followed this saga for years. It's a crying shame it was deliberately ignored.
  - deleted 5y ago
    [deleted]
  - Sesse__ 5y ago
    My first patch to an open-source project ever was to GIMP, as a 16-year-old with zero OSS experience. I actually didn't have much problems getting it merged, so I don't think it was as insular as you make it out. :-) But it wasn't a huge rearchitecting, like 16-bit support is. Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.
    - rleigh 5y ago
      Hi Steinar (long time, no see)! You are right that there are very big differences in scope with large features vs small bugfixes. I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does. This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz). In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate. The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
      - 5y ago
  - blkhawk 5y ago
    That inability doesn't only show in not implementing features but also in the way functions are implemented - A good example is the forced save to xcf introduced in 2.8. Apparently it is more professional. Anyway there is a patch for that by vitalif. You can find prebuild packages here: http://vmx.yourcmc.ru/var/debian/unstable/ http://vmx.yourcmc.ru/var/debian/unstable/ It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings. Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image. There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.
    - kongin 5y ago
      The whole ecosystem around gtk is extremely insular, the devs are hostile and think the users idiots for not doing things the right way. Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
      - redis_mlc 5y ago
        I think most of the gtk maintainers are European, hence the hostility. I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me. As I've mentioned before, HN should ban European IP addresses.
    - trulyme 5y ago
      Agree 100%. About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs. It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions. [0] https://shallowsky.com/software/gimp-save/ https://shallowsky.com/software/gimp-save/
  - BeetleB 5y ago
    > Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.
  - bb88 5y ago
    > The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking. When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint. I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
    - app4soft 5y ago
      > I haven't seen an FLTK app in years. FLTK still widely used in various scientific apps. > Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern? Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2] But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3] Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5] [0] https://twitter.com/app4soft/status/1352349523549577219 https://twitter.com/app4soft/status/1352349523549577219 [1] https://github.com/openvsp/openvsp https://github.com/openvsp/openvsp [2] http://openvsp.org http://openvsp.org [3] https://github.com/rageworx/fl_imgtk https://github.com/rageworx/fl_imgtk [4] https://github.com/fltk-rs https://github.com/fltk-rs [5] https://github.com/fltk-rs/fltk-theme https://github.com/fltk-rs/fltk-theme
      - bb88 5y ago
        It has improved a bit from what I can see, but I wouldn't say it's "modern". Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text. That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
        app4soft 5y ago
- diskzero 5y ago
  We used it at DreamWorks Animation, but also had our own various 2D bitmap editing tools. I can think of a few reasons it fell out of favor in the 3D animated film space. Any process that required artists to come in after a render was complete is bad news for your budget. The more you can accomplish inside of your surfacing and lighting tools, the better. For surface creation, artists in general would prefer to use tools that they are familiar with, and if your pipeline can support export from Photoshop, then that is they are going to want to use. While there are still a lot of proprietary tools in use for lighting and rigging, the days of completely proprietary tool chains and pipelines are over. Software suites of no longer running on SGI boxes with a lot of proprietary formats. A lot of work has been done on interchange formats so it is easier to get your data in and out Maya, Photoshop, etc.
  - dragonwriter 5y ago
    > While there are still a lot of proprietary tools I think you mean something like “bespoke” or maybe just “cinema industry specific”; all your counterexamples to “proprietary tools” are, in fact, proprietary tools.
    - spijdar 5y ago
      Proprietary software but "open systems", in the way that OpenVMS is certainly not open source, same with OpenStep, and several other examples I'm forgetting. But they're documented and accept/output open formats, as opposed to being giant proprietary monoliths. (this is why some people are very insistent on always using the full "FOSS")
    - diskzero 5y ago
      Ah yes. Good point. We wrote a lot of custom software, internal to DreamWorks (or PDI in my case) with no intention of commercializing them. Some of the tools did end up getting used by other studios, but that wasn't an intended goal.
- hallarempt 5y ago
  Well, in the first place the Cinepaint maintainer, Robin Rowe, wasn't a developer. He kind of inherited the tarball with the 16 bit patches, then tried to drum up financial support, without being able to actually maintain the codebase. There was one other developer interested in the codebase, but since Robin never really made releases, their work never really got out. And... Sorry, but "if bitdepth == 8 then, else if bitdepth == 16 all through the codebase just wouldn't have been maintainable for anybody. Then a Scottish university donated a tarball of a research project to the Cinepaint project so then Robin had to maintain two completely different codebases, one which was presented as the successor of the first one. Then Robin decided that the real problem was the antiquated autohell build system, so he decided that having waf, scons and cmake build systems was going to draw in developers. (The blogs announcing that aren't on cinepaint.org anymore, maybe the wayback machine still has them?) That didn't work either, of course, and nothing much happened after that. Cinepaint.org became more and more vandalized, nobody put money in the project, and, well, seeing I'm the Krita maintainer, I probably should stop reminiscing, and go back to coding :-)
thanatos519 5y ago
My favourite memory of Cinepaint was being at a SIGGRAPH exhibition booth (Silicon Grail's I presume) and seeing how they were using GIMP/Cinepaint for wire removal in the X-Files movie. I asked Yosh how the layers dialog looked and he popped it up. It started loading all of the full-def movie frames to make thumbnails, then the machine ran out of memory and IRIX crashed!
- chrisseaton 5y ago
  What was considered full definition for digital work on a film in 1998? Toy Story was less than modern HD, yet you can pay extra to stream it in 4K from Apple! Not sure how that works!
  - ollifi 5y ago
    Cineon 2K was 2048x1556
  - setpatchaddress 5y ago
    ISTR that the early Pixar movie were simply rerendered at higher resolution from the original assets?
    - e1ghtSpace 5y ago
      Correct
    - Maxious 5y ago
      > In 15 years, we'd get 10 doublings, which would make modern computers 1000x faster. Our original Toy Story frames were averaging four hours, which is 240 minutes, so we might naively expect that we could render frames in just 15 seconds. We didn't really achieve that: our average render times were probably on the order of 2-4 minutes per frame (the original productions weren't instrumented to keep accurate statistics on rendertime, and we never bothered to really reinstrument them to do so.) The renders were fast enough that most of Toy Story was rerendered in "render farm white space", we never had any sizeable backlog of work queued on the farm. https://www.quora.com/How-much-faster-would-it-be-to-render-Toy-Story-in-2011-compared-to-how-long-it-took-in-1995?share=1 https://www.quora.com/How-much-faster-would-it-be-to-render-...
autoliteInline 5y ago
Weird, never heard of it. Does it overlap with Discreet or Softimage stuff?
- Wistar 5y ago
  No. Cinepaint was merely a raster paint program with 16-bit colorspace which made it suitable for feature work. It didn't have programmable animation capability but did have onion skinning so that cel-style animation could be done, albeit painfully. Edit: Oh, and that, very importantly, ran on SGI/IRIX.
  - autoliteInline 5y ago
    Oh. More like Lumena (Time Arts/John Dunn). Amazing.
  - mixtur2021 5y ago
    Is https://en.wikipedia.org/wiki/Avid_Matador https://en.wikipedia.org/wiki/Avid_Matador along the similar lines?
    - Wistar 5y ago
      Yes. Very similar.
teruakohatu 5y ago
According to its sourceforge page, Cinepaint is still being maintained. The last update was in May.
- ithinkso 5y ago
  Tangential but, Sourceforge, that's a name I haven't heard in a long time... How are they doing?
  - djcapelis 5y ago
    Not great. Git and then GitHub ate their lunch and then they ended up so desperate they did this: https://www.reddit.com/r/OutOfTheLoop/comments/3aajjs/what_is_sourceforge_and_what_happened_thats/ https://www.reddit.com/r/OutOfTheLoop/comments/3aajjs/what_i... So that pretty much caused whoever still used it to stop. They sold to a new company who stopped that practice but I can’t think of many projects that want a managed SCM that felt there was any reason to switch to sourceforge from GitHub or gitlab after that, which is where most projects have ended up one way or another. Their new owners now call sourceforge a place for “business software” which seems like hopefully the final stage which will bring sourceforge’s long slow decline to its end. Edit: it looks like their latest owner (2020) is slashdot. So. I guess they will capably oversee its continued slide to irrelevance.
    - deleted 5y ago
      [deleted]
    - Groxx 5y ago
      Yeah, the moment they started bundling crapware, the fall was extremely fast. It's a hosting site that's fairly-strongly correlated with technically-adept users: burn them like this and they are never coming back, and they'll loudly tell everyone they know to do likewise.
      - deleted 5y ago
        [deleted]
marcodiego 5y ago
It is interesting to think that GIMP once had such a lead but today is playing catch-up. Blender and Krita area canonical examples success stories in the are now.
- BeetleB 5y ago
  Strong disagree. For image manipulation, Krita is not even close to Gimp's capabilities. I dislike that GIMP keeps being compared to Krita, when the goals of the two projects are quite different. Krita is more for digital artwork, whereas GIMP is more for photo manipulation. Ditto with Blender - it's like comparing Blender with Photoshop - it makes no sense. I used to do heavy photo editing in GIMP. I know of no one who does serious photo editing in Krita.
  - marcodiego 5y ago
    I'm not comparing them in capabilities. I'm comparing them in leadership.
deleted 5y ago
[deleted]
themodelplumber 5y ago
I used Cinepaint all the time back around 2005-2007. You could work with 3D renders at higher bit depths, which meant a lot when you were working with a limited-scope FOSS 3D package on a Linux system in the first place. Much post was done. Thanks to those who worked on the project!
deleted 5y ago
[deleted]
hannob 5y ago
I remember that story and found it really unfortunate. On the one hand you had apparently professionals that were very interested in using a fork of GIMP that provided a specific feature they needed. The GIMP devs said something along the lines of "we plan to implement this in a different way, at some point, we can't tell when this is gonna happen" - and eventually Filmgimp/Cinepaint became a full fork and the chance of getting the support of those movie studios to improve GIMP itself vanished. Wonder what could have been if GIMP would've been smarter on this.
- grandinj 5y ago
  Unfortunately the primary maintainers of GIMP basically have an attitude of "we want to do it our way, and at our pace", and are not willing to accept any patches outside of that pattern. Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.
  - marcodiego 5y ago
    Main problem for gimp now is under-funding. Although slow, their approach may be sound: features will land once they are good enough to work and well written enough to be maintainable. This may be slow but keeps the mechanism working for decades even with a very small team. Studios need features implemented immediately. That usually generates functional but unmaintainable solutions. Note that filmgimp/cinepaint was abandoned by studios as well as gimp developers. What studios should have done: fund main gimp developers and hire other developers to help accelerate the development of GEGL or other multi bpp lib. What gimp developers should have done: try to merge enough of the studios changes to keep them interested.
    - BrightGlow 5y ago
      We can look back in hindsight and say that, but at the time it may have just been that nobody had the resources to do those things. I agree with your sentiment that some forking is preventable, but other times it isn't. Changing the fundamental design of the program tends to be one of those things that can't really be merged without causing a lot of other problems.

190 points by marcodiego 5y ago

mixmastamyk 5y ago

Unfortunately, there’s no info here about why it fell out of favor. Only up to the rename.

rleigh 5y ago
The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. Look at the difference between how different open-source projects operate. Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. It's kind of sad that the Cinepaint people got several paid staff to lift the GIMP functionality to the point it had very high-profile commercial use with some really useful features, and yet the GIMP developers were too stubborn to acknowledge this effort and work with them to get the functionality into the GIMP core. Sadly, this is not unique to the GIMP. I, and other commercial developers, had exactly the same experience with GTK+ and GNOME libraries. The developers wanted to hack on their pet thing, ignore outside contributions, and this is simply not compatible with commercial timelines and realities. But it can be, and it can work very well, for projects which are willing to engage with outside work. It can work out to be very mutually beneficial with some give and take on both sides. I was on the GIMP mailing lists at the time and followed this saga for years. It's a crying shame it was deliberately ignored.
- deleted 5y ago
  [deleted]
- Sesse__ 5y ago
  My first patch to an open-source project ever was to GIMP, as a 16-year-old with zero OSS experience. I actually didn't have much problems getting it merged, so I don't think it was as insular as you make it out. :-) But it wasn't a huge rearchitecting, like 16-bit support is. Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.
  - rleigh 5y ago
    Hi Steinar (long time, no see)! You are right that there are very big differences in scope with large features vs small bugfixes. I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does. This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz). In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate. The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
    - 5y ago
- blkhawk 5y ago
  That inability doesn't only show in not implementing features but also in the way functions are implemented - A good example is the forced save to xcf introduced in 2.8. Apparently it is more professional. Anyway there is a patch for that by vitalif. You can find prebuild packages here: http://vmx.yourcmc.ru/var/debian/unstable/ http://vmx.yourcmc.ru/var/debian/unstable/ It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings. Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image. There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.
  - kongin 5y ago
    The whole ecosystem around gtk is extremely insular, the devs are hostile and think the users idiots for not doing things the right way. Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
    - redis_mlc 5y ago
      I think most of the gtk maintainers are European, hence the hostility. I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me. As I've mentioned before, HN should ban European IP addresses.
  - trulyme 5y ago
    Agree 100%. About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs. It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions. [0] https://shallowsky.com/software/gimp-save/ https://shallowsky.com/software/gimp-save/
- BeetleB 5y ago
  > Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.
- bb88 5y ago
  > The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking. When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint. I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
  - app4soft 5y ago
    > I haven't seen an FLTK app in years. FLTK still widely used in various scientific apps. > Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern? Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2] But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3] Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5] [0] https://twitter.com/app4soft/status/1352349523549577219 https://twitter.com/app4soft/status/1352349523549577219 [1] https://github.com/openvsp/openvsp https://github.com/openvsp/openvsp [2] http://openvsp.org http://openvsp.org [3] https://github.com/rageworx/fl_imgtk https://github.com/rageworx/fl_imgtk [4] https://github.com/fltk-rs https://github.com/fltk-rs [5] https://github.com/fltk-rs/fltk-theme https://github.com/fltk-rs/fltk-theme
    - bb88 5y ago
      It has improved a bit from what I can see, but I wouldn't say it's "modern". Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text. That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
      - app4soft 5y ago
diskzero 5y ago
We used it at DreamWorks Animation, but also had our own various 2D bitmap editing tools. I can think of a few reasons it fell out of favor in the 3D animated film space. Any process that required artists to come in after a render was complete is bad news for your budget. The more you can accomplish inside of your surfacing and lighting tools, the better. For surface creation, artists in general would prefer to use tools that they are familiar with, and if your pipeline can support export from Photoshop, then that is they are going to want to use. While there are still a lot of proprietary tools in use for lighting and rigging, the days of completely proprietary tool chains and pipelines are over. Software suites of no longer running on SGI boxes with a lot of proprietary formats. A lot of work has been done on interchange formats so it is easier to get your data in and out Maya, Photoshop, etc.
- dragonwriter 5y ago
  > While there are still a lot of proprietary tools I think you mean something like “bespoke” or maybe just “cinema industry specific”; all your counterexamples to “proprietary tools” are, in fact, proprietary tools.
  - spijdar 5y ago
    Proprietary software but "open systems", in the way that OpenVMS is certainly not open source, same with OpenStep, and several other examples I'm forgetting. But they're documented and accept/output open formats, as opposed to being giant proprietary monoliths. (this is why some people are very insistent on always using the full "FOSS")
  - diskzero 5y ago
    Ah yes. Good point. We wrote a lot of custom software, internal to DreamWorks (or PDI in my case) with no intention of commercializing them. Some of the tools did end up getting used by other studios, but that wasn't an intended goal.
hallarempt 5y ago
Well, in the first place the Cinepaint maintainer, Robin Rowe, wasn't a developer. He kind of inherited the tarball with the 16 bit patches, then tried to drum up financial support, without being able to actually maintain the codebase. There was one other developer interested in the codebase, but since Robin never really made releases, their work never really got out. And... Sorry, but "if bitdepth == 8 then, else if bitdepth == 16 all through the codebase just wouldn't have been maintainable for anybody. Then a Scottish university donated a tarball of a research project to the Cinepaint project so then Robin had to maintain two completely different codebases, one which was presented as the successor of the first one. Then Robin decided that the real problem was the antiquated autohell build system, so he decided that having waf, scons and cmake build systems was going to draw in developers. (The blogs announcing that aren't on cinepaint.org anymore, maybe the wayback machine still has them?) That didn't work either, of course, and nothing much happened after that. Cinepaint.org became more and more vandalized, nobody put money in the project, and, well, seeing I'm the Krita maintainer, I probably should stop reminiscing, and go back to coding :-)

thanatos519 5y ago

My favourite memory of Cinepaint was being at a SIGGRAPH exhibition booth (Silicon Grail's I presume) and seeing how they were using GIMP/Cinepaint for wire removal in the X-Files movie. I asked Yosh how the layers dialog looked and he popped it up. It started loading all of the full-def movie frames to make thumbnails, then the machine ran out of memory and IRIX crashed!

chrisseaton 5y ago
What was considered full definition for digital work on a film in 1998? Toy Story was less than modern HD, yet you can pay extra to stream it in 4K from Apple! Not sure how that works!
- ollifi 5y ago
  Cineon 2K was 2048x1556
- setpatchaddress 5y ago
  ISTR that the early Pixar movie were simply rerendered at higher resolution from the original assets?
  - e1ghtSpace 5y ago
    Correct
  - Maxious 5y ago
    > In 15 years, we'd get 10 doublings, which would make modern computers 1000x faster. Our original Toy Story frames were averaging four hours, which is 240 minutes, so we might naively expect that we could render frames in just 15 seconds. We didn't really achieve that: our average render times were probably on the order of 2-4 minutes per frame (the original productions weren't instrumented to keep accurate statistics on rendertime, and we never bothered to really reinstrument them to do so.) The renders were fast enough that most of Toy Story was rerendered in "render farm white space", we never had any sizeable backlog of work queued on the farm. https://www.quora.com/How-much-faster-would-it-be-to-render-Toy-Story-in-2011-compared-to-how-long-it-took-in-1995?share=1 https://www.quora.com/How-much-faster-would-it-be-to-render-...

autoliteInline 5y ago

Weird, never heard of it. Does it overlap with Discreet or Softimage stuff?

Wistar 5y ago
No. Cinepaint was merely a raster paint program with 16-bit colorspace which made it suitable for feature work. It didn't have programmable animation capability but did have onion skinning so that cel-style animation could be done, albeit painfully. Edit: Oh, and that, very importantly, ran on SGI/IRIX.
- autoliteInline 5y ago
  Oh. More like Lumena (Time Arts/John Dunn). Amazing.
- mixtur2021 5y ago
  Is https://en.wikipedia.org/wiki/Avid_Matador https://en.wikipedia.org/wiki/Avid_Matador along the similar lines?
  - Wistar 5y ago
    Yes. Very similar.

teruakohatu 5y ago

According to its sourceforge page, Cinepaint is still being maintained. The last update was in May.

ithinkso 5y ago
Tangential but, Sourceforge, that's a name I haven't heard in a long time... How are they doing?
- djcapelis 5y ago
  Not great. Git and then GitHub ate their lunch and then they ended up so desperate they did this: https://www.reddit.com/r/OutOfTheLoop/comments/3aajjs/what_is_sourceforge_and_what_happened_thats/ https://www.reddit.com/r/OutOfTheLoop/comments/3aajjs/what_i... So that pretty much caused whoever still used it to stop. They sold to a new company who stopped that practice but I can’t think of many projects that want a managed SCM that felt there was any reason to switch to sourceforge from GitHub or gitlab after that, which is where most projects have ended up one way or another. Their new owners now call sourceforge a place for “business software” which seems like hopefully the final stage which will bring sourceforge’s long slow decline to its end. Edit: it looks like their latest owner (2020) is slashdot. So. I guess they will capably oversee its continued slide to irrelevance.
  - deleted 5y ago
    [deleted]
  - Groxx 5y ago
    Yeah, the moment they started bundling crapware, the fall was extremely fast. It's a hosting site that's fairly-strongly correlated with technically-adept users: burn them like this and they are never coming back, and they'll loudly tell everyone they know to do likewise.
    - deleted 5y ago
      [deleted]

marcodiego 5y ago

It is interesting to think that GIMP once had such a lead but today is playing catch-up. Blender and Krita area canonical examples success stories in the are now.

BeetleB 5y ago
Strong disagree. For image manipulation, Krita is not even close to Gimp's capabilities. I dislike that GIMP keeps being compared to Krita, when the goals of the two projects are quite different. Krita is more for digital artwork, whereas GIMP is more for photo manipulation. Ditto with Blender - it's like comparing Blender with Photoshop - it makes no sense. I used to do heavy photo editing in GIMP. I know of no one who does serious photo editing in Krita.
- marcodiego 5y ago
  I'm not comparing them in capabilities. I'm comparing them in leadership.

deleted 5y ago

[deleted]

themodelplumber 5y ago

I used Cinepaint all the time back around 2005-2007. You could work with 3D renders at higher bit depths, which meant a lot when you were working with a limited-scope FOSS 3D package on a Linux system in the first place. Much post was done. Thanks to those who worked on the project!

deleted 5y ago

[deleted]

hannob 5y ago

I remember that story and found it really unfortunate. On the one hand you had apparently professionals that were very interested in using a fork of GIMP that provided a specific feature they needed. The GIMP devs said something along the lines of "we plan to implement this in a different way, at some point, we can't tell when this is gonna happen" - and eventually Filmgimp/Cinepaint became a full fork and the chance of getting the support of those movie studios to improve GIMP itself vanished. Wonder what could have been if GIMP would've been smarter on this.

grandinj 5y ago
Unfortunately the primary maintainers of GIMP basically have an attitude of "we want to do it our way, and at our pace", and are not willing to accept any patches outside of that pattern. Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.
- marcodiego 5y ago
  Main problem for gimp now is under-funding. Although slow, their approach may be sound: features will land once they are good enough to work and well written enough to be maintainable. This may be slow but keeps the mechanism working for decades even with a very small team. Studios need features implemented immediately. That usually generates functional but unmaintainable solutions. Note that filmgimp/cinepaint was abandoned by studios as well as gimp developers. What studios should have done: fund main gimp developers and hire other developers to help accelerate the development of GEGL or other multi bpp lib. What gimp developers should have done: try to merge enough of the studios changes to keep them interested.
  - BrightGlow 5y ago
    We can look back in hindsight and say that, but at the time it may have just been that nobody had the resources to do those things. I agree with your sentiment that some forking is preventable, but other times it isn't. Changing the fundamental design of the program tends to be one of those things that can't really be merged without causing a lot of other problems.