Re: Re: Linuxmovies-general digest, Vol 1 #217 - 8 msgs
salsaman <salsaman-qWit8jRvyhVmR6Xm/[email protected]> Tue, 27 Dec 2005 23:43:52 +0100
| Newsgroups | gmane.comp.video.linux.movies |
|---|---|
| Message-ID | <[email protected]> |
Bob Friesenhahn wrote: > On Tue, 27 Dec 2005, salsaman wrote: > >> Hi Bob, >> that is not strictly true, although LiVES is currently aimed at home >> users. > > > Salsaman, I did not mean to criticize LiVES in any way. Certainly > different types of productions have different reqirements, and being > able to edit video at home is a quite useful application. It would > not make sense to burden this sort of user with a cumbersome framework. > > The reason why I asked about a DI framework oriented toward > studio-grade production is because I have not heard of an open-source > framework which supports these requirements. An open-source framework > would be quite useful. > > An example of a successful open-source framework is eclipse > (http://eclipse.org/) which is a framework for building software, and > is now strongly supported by many significant companies. These > companies are discarding their existing proprietary environments and > are offering smaller add-ons to eclipse instead. The file-based DI > process needs an industry-supported open framework like this. > Hi Bob, don't worry, I wasn't taking your remarks as criticism, at least not in the negative sense. I am not sure what you mean by "DI framework". >> Second, for colorspaces, if you look at the current spec for LiVES >> realtime processing: >> http://www.xs4all.nl/~salsaman/lives/docs/weedspec.txt >> you will see that one of the supported palettes is RGBA float (packed >> 32bit float giving a 128 bit pixel size) which should be adequate for >> any future use. > > > 16-bit samples are more than sufficient to support any > editing/post-production requirement. 13-bits linear or 10 bits log, > are sufficient. Only the rendering/HDR folks want more than 16-bits. > Well that is a possibility for the future. One of my fellow developers Oyvind Kolas has some very fast int->float convertors, you might be interested also: http://pippin.gimp.org/babl/ so 16bit int -> 32 bit float can be done very easily. > Professional-grade video is still limited to 10-bits linear. The only > exception to this are cameras which output using 10-bit log encoding > (e.g. Viper). > >> The reason this palette is not used so much now: >> - there are no readily available sources for such image formats >> - AFAIK there is no intermediate image format for such frames > > > One format which can be easily used is TIFF. TIFF supports 32-bit and > 64-bit floats, and Photoshop CS2 has introduced (draft documented) > support for 16 and 24-bit floats in TIFF. There is the possibility of > using OpenEXR or other HDR formats. DPX can also support 32-bit > floats although I don't know of any applications supporting it. The > FITS format (for astronomy applications) supports floating point images. > > Bob Thanks, that is useful to know. I was not aware that TIFF could store float image data. Regards, Salsaman. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click