similar to: Call for comments: OggUVS

On Tue, Nov 08, 2005 at 03:33:57PM -0500, John Koleszar wrote: > > In terms of colorspaces, it seems to me that the only way to completely > describe the colorspace is to provide the transform matricies to or from > some reference colorspace. Is this a valid statement? Except there are not enough colorspaces in use to need to do this, as far as I've read at least.. a set of

Timothy B. Terriberry wrote: >Chapter 4 of the Theora specification does a reasonable job of laying >out all of the possible parameters for a Y'CbCr-style color space, which >includes as a subset those needed for RGB. Much more detailed >information is available from Charles Poynton's Color and Gamma FAQs: >http://www.poynton.com/Poynton-color.html >If you wish to do any

I take it you are talking about what is listed under alternative format ? If you have an implementation... you must have a list of enumeration fields... could you put them on the wiki. If we are asking for final comments... the wiki should be tidied up. The original format removed if the general consensus is that this is more on the right track... which it looks to be. Zen. ----- Original

Greetings, After pouring over the documentation for the 'colorspace' package, I have not been able to figure out how the plot() method converts colorspace coordinates to RGB values for display on the screen. I am convert between colorspaces with the various as() methods... but cannot seem to find a way to extract RGB (i.e. for displaying on a computer screen) triplets from color space

Hi, The move to sRGB is nice, is there any interest in adding an interface to lcms, http://www.littlecms.com, to allow gamut matching? I can think of a lot of instances where I would like to render a figure as it would appear on my printer. This is probably best done as a separate package though, at least at first. Nicholas Martin Maechler wrote: >>>>>> "Paul" ==

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

On 8/17/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > OK, then yuv4mpeg will have the magic number: char[8]: 'YUV4MPEG'. Which was previously for those not paying attention char[9]: 'YUV4MPEG2'. > Also, can you put the link to the spec into > http://wiki.xiph.org/index.php/MIMETypesCodecs ? AFAIK, that is just a matter of putting a [[OggUVS]] in

> If you want to limit the allowable values for the FourCC field, I don't have > an issue with that, but I think it's useful for decoders to be able to tell > easily whether or not they support the format (since most decoders will > operate on the well defined formats) and useful for encoders, since most data > sources are described by a fourcc (the exception being

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

Arc wrote: >Not the camera, only the application which goes between the camera and >OggStream. Plus, changing between packed and planar is easy, my reason for >wanting to avoid packed is there's simply too many different ways to do it. > > My argument is that that application shouldn't have to convert to a fixed format. It should be able to say here's some YUY2

I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

Hi derf_, all, this is for the spec doc derf is working on - as discussed on irc. More soon (hopefully :) Cherio, Silvia. <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: hilbert-block.fig Type: image/x-xfig Size: 3610 bytes Desc: hilbert-block.fig Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040512/483ac379/hilbert-block-0001.bin

Hi all, is there a way to automatically convert uploaded images to an RGB colorspace? I have a small intranet app, in which people can upload images. Sometimes a large 300dpi CMYK image intended for print sneaks in and causes trouble... Many thanks in advance, Nicky

Hi everyone, I am trying to install colorspace (needed as part of my favourite ggplot2) on R v 2.7.0 running under ubuntu 7.04. The package is provided as source files and the compilation fails as below. I suspect this might be a problem with gcc v3/v4 incompatibility (or anything else), but I don't really know how to resolve it. Any advice will be appreciated - or perhaps somebody has got

Dear all, I'm having problems installing the colorspace package on Red Hat Enterprise Linux 5: * Installing *source* package 'colorspace' ... ** libs gcc -std=gnu99 -I/usr/lib/R/include -I/usr/lib/R/include -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic