[HN Gopher] Cinepaint: The long forgotten GIMP fork that once po...
___________________________________________________________________
Cinepaint: The long forgotten GIMP fork that once powered the
cinema industry
Author : marcodiego
Score : 64 points
Date : 2021-09-18 18:43 UTC (4 hours ago)
(HTM) web link (cinepaint.bigasterisk.com)
(TXT) w3m dump (cinepaint.bigasterisk.com)
| autoliteInline wrote:
| Weird, never heard of it.
|
| Does it overlap with Discreet or Softimage stuff?
| Wistar wrote:
| 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 wrote:
| Oh. More like Lumena (Time Arts/John Dunn).
|
| Amazing.
| teruakohatu wrote:
| According to its sourceforge page, Cinepaint is still being
| maintained. The last update was in May.
| ithinkso wrote:
| Tangential but, Sourceforge, that's a name I haven't heard in a
| long time... How are they doing?
| djcapelis wrote:
| 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_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]
| Groxx wrote:
| 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.
| pwdisswordfish8 wrote:
| "Their latest owner is Slashdot" is true, but it's true in
| the sense that the company that both Sourceforge and
| Slashdot _became_ Slashdot.
| mlinksva wrote:
| https://en.wikipedia.org/wiki/CinePaint and
| https://en.wikipedia.org/wiki/SourceForge each seem to be
| reasonably up to date.
| marcodiego wrote:
| 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.
| mixmastamyk wrote:
| Unfortunately, there's no info here about why it fell out of
| favor. Only up to the rename.
| rleigh wrote:
| 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]
| diskzero wrote:
| 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.
| thanatos519 wrote:
| 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 wrote:
| 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 wrote:
| Cineon 2K was 2048x1556
| setpatchaddress wrote:
| ISTR that the early Pixar movie were simply rerendered at
| higher resolution from the original assets?
| pwdisswordfish8 wrote:
| What's confusing? They can re-render the scenes from the
| original source. At some point in the transition from VHS to
| DVD to Blu-Ray, they may have even done a "remastered" re-
| release (hiring staff to touch up textures and so on), and if
| so, they could make use of that work, too.
| chrisseaton wrote:
| > they may have even done a "remastered" re-release
|
| Are you just guessing?
| pwdisswordfish8 wrote:
| Not guessing anything, because I didn't say it even
| happened.
|
| Whether it happened or not doesn't change that even if
| the original theatrical version was 1536x922, re-
| rendering for higher resolutions is trivial.
| jasonwatkinspdx wrote:
| Rerendeirng old cinema cg is anything but trivial.
| Production pipelines are incredibly complex and are a
| fast moving target. Getting something going again is a
| very complex and tedious task of software archeology
| against projects that often only had a single company
| using them. Many dependencies will be unavailable or
| incompatible with current systems.
|
| When old content that doesn't have a high resolution film
| or digital master copy is remastered to HD, it's done
| using super resolution tools that do their best to infer
| extra detail based on the existing data.
| Sesse__ wrote:
| Also, often special effects are done as manual one-offs
| on top of what comes out of the renderer (with whatever
| software package and techniques that happened to fit the
| bill for that particular effect); it's not like you can
| just type "make" and out comes the movie. It's certainly
| _easier_ to do a higher-res version of an animated movie
| than a live-action one, but it's still a lot of work.
| [deleted]
| themodelplumber wrote:
| 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!
___________________________________________________________________
(page generated 2021-09-18 23:00 UTC)