You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(16) |
Jul
(6) |
Aug
(20) |
Sep
(6) |
Oct
(2) |
Nov
(9) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(29) |
Feb
(16) |
Mar
(9) |
Apr
(75) |
May
(66) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(8) |
Dec
|
2006 |
Jan
(3) |
Feb
(15) |
Mar
(6) |
Apr
(3) |
May
(6) |
Jun
(31) |
Jul
(1) |
Aug
(12) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
(59) |
Mar
(37) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(3) |
2008 |
Jan
|
Feb
(2) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(32) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(4) |
Nov
|
Dec
|
2009 |
Jan
(5) |
Feb
(10) |
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(30) |
Aug
(10) |
Sep
|
Oct
|
Nov
(5) |
Dec
(15) |
2010 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(6) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(12) |
2011 |
Jan
(6) |
Feb
(6) |
Mar
(12) |
Apr
(19) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Dave H. <dh...@ap...> - 2004-06-30 18:03:28
|
Paul Miller <pa...@pr...> sez: > I believe the CoreImage API is a an API for hardware accelerated image > processing (ie. via GPU shaders). It provides a standard set of > pre-built "filters" that are presumably built using GPU shaders and > hidden through some API. There isn't really any detail but it seems > to be QuickTime related. I suppose Core Image is sort of QuickTime related, because you can apply Core Image effects to QuickTime movies. But Core Image doesn't require the use of QuickTime. Core Image details are downloadable from Apple's site if you're an ADC member: For more information, see http://developer.apple.com/prereleasesoftware/ > From what I have seen of Motion (which is Apple's real-time end-user > software which seems to be built on CoreImage), this API is limited to > certain resolutions and 8-bit components. The Motion limitations are app limitations, not Core Image limitations. Motion doesn't require Core Image, which is scheduled to ship months after Motion. By default Core Image works primarily with 32-bit float pixel components (although you can use other formats). > As OFX is a cross-platform software-based architecture, I don't see > CoreImage as being too relevant (especially as there are no technical > details or APIs documented yet). That seems like an overly broad generalization. It's true that Core Image only runs on Mac OS X, but that doesn't make it irrelevant. Maybe the Mac version of an OFX plug-in would want to take advantage of Core Image. On the other hand, I suppose an OFX plug-in developer could handle that without any direct support for Core Image in the OFX APIs. As for Core Image technical details and APIs, see the ADC Member Site as noted above. ----------------- Dave Howell OFX List Lurker :-) Apple Pro Apps |
From: Paul M. <pa...@pr...> - 2004-06-30 01:03:38
|
>Has anyone had the chance to compare/contrast the OFX api to the >recently announced (but not described) CoreImage api from Apple? > http://www.apple.com/macosx/tiger/core.html I believe the CoreImage API is a an API for hardware accelerated image processing (ie. via GPU shaders). It provides a standard set of pre-built "filters" that are presumably built using GPU shaders and hidden through some API. There isn't really any detail but it seems to be QuickTime related. From what I have seen of Motion (which is Apple's real-time end-user software which seems to be built on CoreImage), this API is limited to certain resolutions and 8-bit components. As OFX is a cross-platform software-based architecture, I don't see CoreImage as being too relevant (especially as there are no technical details or APIs documented yet). BTW - "hi". I helped you guys write an Elastic Reality I/O module a LONG time ago. -- Paul Miller | pa...@pr... | www.profoundeffects.com VP of Engineering, Profound Effects, Inc. | Got Tivo? |
From: Rod B. <rg...@il...> - 2004-06-30 00:33:52
|
Has anyone had the chance to compare/contrast the OFX api to the recently announced (but not described) CoreImage api from Apple? http://www.apple.com/macosx/tiger/core.html RGB |
From: Bruno N. <br...@th...> - 2004-06-29 17:51:29
|
Any other comments from anyone before I push it to 1.0? I have committed (but not tagged) the changes that Kimbal suggested. b Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-28 19:12:53
|
On 27 Jun 2004, at 07:23, Kimball Thurston wrote: > I don't know why I didn't notice it earlier, but could we change the > types for > pluginAPI and pluginIdentifier in OfxPlugin to be const char * instead > of > char *? I think they should be const, and I believe the default > behavior in > gcc 3.4 or 3.5 is going to switch so that string literals are const by > default, hence causing a compile error... Well spotted Kimbal. I'll do that change and commit it. Then onwards to V1.0 goodness. b Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Kimball T. <kd...@ad...> - 2004-06-28 16:23:50
|
On Monday 28 June 2004 08:59 am, Matthias Melcher wrote: > On Sat, 2004-06-26 at 23:23, Kimball Thurston wrote: > > Also, not that I want to change it (well maybe, depending on the answer), > > but can someone remind me why we chose to use strings for the actions > > coming into the plugin entry point as opposed to a good set of integers? > > When looking at the communication between your plugin an your host, and > you get an unknown ID, what do you prefer: > "kNukeExtMultithreadEachScanline" or "16745" true. I remember now. Even with a utility function / table to translate integer into string, you'd end up with the occasional "Error -42 unknown". I guess I was assuming that for a particular type of plugin, the set of strings corresponding to actions, or for that matter properties (not parameters!), would have to be decided on first, and codified in a header file so that everyone knew about it. In which case an integer would work just fine (with an error translation utility)... The reason I ask is that a switch statement in places like the main entry point would seem to read better to me than a set of if - else if statements. And integers could be reserved pretty easily by a #define kOfxLastAction 100, and a comment saying all actions < kOfxLastAction are reserved... Not that big of a deal. Just wondering as I was (finally) playing around with things... - Kimball |
From: Matthias M. <wo...@d2...> - 2004-06-28 15:59:56
|
On Sat, 2004-06-26 at 23:23, Kimball Thurston wrote: > Also, not that I want to change it (well maybe, depending on the answer), but > can someone remind me why we chose to use strings for the actions coming into > the plugin entry point as opposed to a good set of integers? When looking at the communication between your plugin an your host, and you get an unknown ID, what do you prefer: "kNukeExtMultithreadEachScanline" or "16745" The reason for using strings, IIRC, is to provide an easy way to expand and add more arguments and actions without the need of coordinating numbers. If you use int's, it is only a matter of days until two different developers will use the same number for different extensions, which will lead to confusion and later certain insanity. I bet ya that '42' will be taken within a week. With strings, just start the string with the name of your application/company/mothers maiden name and you can be pretty sure that it'll be unique. Also, it is really easy to output plugin communication logs, even if you don't know the meaning of that particular value, but the string will give you an idea. |
From: Kimball T. <kd...@ad...> - 2004-06-27 06:23:30
|
I don't know why I didn't notice it earlier, but could we change the types for pluginAPI and pluginIdentifier in OfxPlugin to be const char * instead of char *? I think they should be const, and I believe the default behavior in gcc 3.4 or 3.5 is going to switch so that string literals are const by default, hence causing a compile error... Also, not that I want to change it (well maybe, depending on the answer), but can someone remind me why we chose to use strings for the actions coming into the plugin entry point as opposed to a good set of integers? thanks, Kimball |
From: Bruno N. <br...@th...> - 2004-06-23 17:44:52
|
Hi All, the penultimate RC release has just been posted. See the release notes for the changes. I have no intention of changing 1.0 any further. If I get no objections, I will call this version 1.0 on Monday. b Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-16 10:39:36
|
Hi All, I've had two requests to extend RC7, these are two extra properties, and a slight change in a function signature. The two extra properties are.... - one to indicate the file path where the host found the plug-in, - one to indicate if the instance is running in an interactive host, or if it is running on a render-only host. I would like to change the function signature of OfxThreadFunctionV1 in ofxMultiThread.h typedef void (OfxThreadFunctionV1)(int threadIndex, unsigned int threadMax,void *customArg); to typedef void (OfxThreadFunctionV1)(unsigned int threadIndex, unsigned int threadMax, void *customArg); then I want to call it a day an call it V1.0. I have only had one volunteer (Matthias from D2 software) to help me on the project with write access. I am very happy to have him work with me (he's good at spotting my bugs). Does anybody else want access? b Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-07 11:35:36
|
Hi All, I'm happy with RC7 and would like it to turn into 1.0. Anyone have any feelings/thoughts about this? The thing that may cause concern is the DTD for the resource file spec, as I am new to XML. it seems sane to me and nobody has criticised it yet. bruno Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-02 12:56:24
|
Hi All, I've just posted 1.0RC7 to... http://sourceforge.net/projects/openfx and click on the 'files' link to get it. It bundles in the XML dtd and resource spec, the infinite RoD spec and changes to the examples to show this working. It is binary compatible with RC6. However there are 2 new #defines to support the infinite RoD spec. bruno Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-01 13:50:53
|
Hi, I've gone and committed my final changes to the DTD and documentation to support it. Please peruse, use and disabuse me of any inanity or profanity that would turn into a coding calamity. b Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Bruno N. <br...@th...> - 2004-06-01 13:47:54
|
Hello to the new openfx developers list! Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |
From: Matthias M. <wo...@d2...> - 2004-05-25 21:15:57
|
...for creating the account and moving all the code over. I hope that everyone will make the jump to the new list! Matthias |
From: Bruno N. <br...@th...> - 2004-05-25 08:53:40
|
test Bruno Nicoletti The Foundry, London, England Visual Effects Software tel: (44) 020 7434 0449 fax: (44) 020 7434 1550 http://www.thefoundry.co.uk |