[clug] Video editing under linux and financial incentives.

[Edward C. Lang]

On Wed, Jun 09, 2004 at 12:01:24PM +1000, Sam Couter wrote:
> Edward C. Lang <edlang at tsumakin.net> wrote:
> > I'm feeling the same way about colour space management / workflow at the
> > moment, for photo editing. Colour proofing in Linux/X with GIMP/dcraw
> > proved to be too difficult, compared to things like Photoshop CS and
> > Capture One Pro. I haven't seen much effort sunk into this area in OSS. 
> 
> 1) What do you expect for nothing?

Um. Nothing? I don't think that's a very useful question to ask when
attempting Linux advocacy. 

> 
> 2) Use the source, Edward. Or, provide some incentive for somebody else
> to do so.

It would be working on a lot of source, and would involve interfacing
with a lot of people. At the moment I don't have the motivation or
desire to do either of those thing. I'd much prefer to continue taking
photographs. 

Isn't the satisfaction of enabling a large number of people to remain at
the height of their productivity and creativity, using OSS instead of
using proprietary software, incentive enough? 

With only a rough working knowledge of the components I used in my
workflow, I'd say the following would need to be modified or resolved:

  1) I've no idea of the state of ICC profiles in X; but I do know that
  it is tricky managing the gamma and having a display gamma that is
  consistent with those of OS X and Windows. I can't remember if Raph
  Levien is doing anything related to this in his work on Ghostscript,
  but his advogato diary has included some good points on this subject
  in the past.

  2) Colour profile / space support in the GIMP, as well as being able
  to handle a larger number of (proprietary) file formats, 16-bit files,
  and various versioning and metadata formats. The FilmGIMP (or whatever
  it and its derivatives are called these days) has some support for
  16-bit files, if I recall correctly, but I'm not sure if that support
  was merged into GIMP 2. I hope it doesn't take another film like
  Titanic for that sort of development to occur, because a) I thought it
  was a bad film and b) it involved a lot more money than I have in my
  bank account.

  3) Interactive manipulation and decoding of the various camera
  companies' proprietary raw formats. Seriously, things like Capture One
  Pro and the Adobe RAW plugin are beyond compare. I enjoyed using dcraw
  for a while, but when I moved to shooting in the AdobeRGB colour space
  and at specific temperatures (for white balance) I rapidly grew
  annoyed by it. dcraw is also an example of reverse engineering, rather
  than being written with the assistence / guidance of the camera 
  companies' engineers.

  4) UI design. For better or for worse, Microsoft, Apple, Adobe and
  whomever else can enforce a consistent UI policy across their
  products. And, many tasks can be completed in the one program, which I
  found sped up my workflow, rather than slowing it down or limiting it.
  I wish, I wish some entity could come along and take over the X team,
  the GIMP team, the GNOME/KDE teams, etc to solve this issue, but
  personally I think you'd have better success at herding cats.

  5) Dealing with, and working around patents, both software and
  otherwise. Colour management and control seems to be even more
  proprietised than software. So, lawyers and a lot of money for
  royalties may be necessary.

  6) Finding artists to work with, and software engineers that enjoy
  working with artists. I've been on both sides of the fence and seen
  how easily it is for one side to scoff at the other. 

It's not a topic that I pulled out of thin air, at a whim, in response
to John's email. I'd be more than willing to work with you and others in
this area, come July. 
 
Regards,

Edward.

-- 

http://www.tsumakin.net/