Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

CS 4 now available...

mdharrington said:
(you can get 64 bit in a mac right now....just not anything with a user interface)
Click to expand...

What are you smoking? :umm: ...might want to double-check your facts.
 
Quote:
Originally Posted by mdharrington
(you can get 64 bit in a mac right now....just not anything with a user interface)

What are you smoking? ...might want to double-check your facts.
Click to expand...

this is true for carbon apps....
well not totally impossible there is a workaround

As mentioned earlier, the use of a 64-bit address space is limited to non-GUI applications in Tiger. This doesn't mean, however, that the results of a 64-bit enabled computation can't be displayed on the screen. The strategy that you should use is to create two separate executables that are cooperative.

this is from apples developer site
http://developer.apple.com/macosx/64bit.html

a lot of developers have bitched about this hence no adobe 64 bit for mac...no maya 64, no lightwave 64, no syntheyes 64 bit, no nuke 64 bit... ect ect ect...
all those listed do have windows 64 bit counterparts

from syntheyes website
http://www.ssontech.com/sixty4.htm#OSX

To Our Mac OS X Customers
Apple has announced that Leopard and future Apple operating systems will not support 64-bit applications using Carbon, their current application environment. Apple is requiring developers to re-write their applications using Apple's proprietary language and environment in order to use 64-bit features. It's a startling stance for a company that is already several years behind in the real 64-bit world.

If you want to use all the RAM in your machine, fire up your Mac in 64-bit Vista or XP, and run 64-bit SynthEyes today

since you may know better....list some true 64 bit apps that you know of for osx?
 
From the CS4 readme file:
Adobe Photoshop Extended natively supports 64-bit editions of Windows. Adobe Premiere Pro, After Effects, Soundbooth, Encore, and Adobe OnLocation are certified on 64-bit Windows Vista.
So no native support for 64 bits, it just works on 64 bits.

Bit disappointed with CS4 “upgrade”
First of all it is not really upgrade but full install in the separate directory, leaving you with two CS3 and CS4 icons.
Opening and converting old CS3 project looks like big trouble, I did try just a few and had all kinds of format and playback size idiosyncrasies.
No support for R3D files and no support for RED QT proxies, this one gives you error ‘codec missing’.
Looks like in November there will be support for plugin first, than we have to get this plugin from RED.

We have a long route to haven:-)

So far it looks like there will be long painful debugging process, especially if you have extensive library of projects from CS3.

I wonder if we get this ugly banding when coding from RED 16 bit to 8 bit BluRay H.264 or mpeg2.
 
Andrew said:
From the CS4 readme file:

I wonder if we get this ugly banding when coding from RED 16 bit to 8 bit BluRay H.264 or mpeg2.
Click to expand...

I have been making BluRay discs from files down converted to 1080P in RedCine using CS3 and they look really good. (Files were converted using only the highest quality settings RedCine offers of course.) I might be wrong, but I don't think the BluRay file produced is 8 bit. mpeg2 doesn't look very good of course.

Dave
 
Dave, what final output format did you use?
Did you try H.264 for BR?
I do not have any problem with TIF or DPX.
 
mdharrington said:
this is true for carbon apps....
well not totally impossible there is a workaround

As mentioned earlier, the use of a 64-bit address space is limited to non-GUI applications in Tiger. This doesn't mean, however, that the results of a 64-bit enabled computation can't be displayed on the screen. The strategy that you should use is to create two separate executables that are cooperative.
Click to expand...

Hey, I was just picking a nit -- you said that you couldn't have an interface on a 64bit app. Not true. But if we want to analyze the situation...

Yes, as far as Tiger is concerned, the situation is pretty dire. As far as Leopard goes, it's better. BTW: that 64bit link you have there, the first one, is nearly 3 years old. There are more abilities under Leopard. Which in itself is a problem -- software developers, especially larger ones with establish customer bases, are not willing to let go of Tiger support right now. Perhaps this will change once Snow Leopard starts shipping?

The compilers are fully 64bit enabled (when compiling / linking for Leopard only), but the Carbon API is still 32bit. For now, this mean Applications built to only function under Leopard will have more options, but sill run into the limitations of the Carbon API. This leaves software developers with a couple options, none of them great. These options are:

1> Port all code base from C/C++ and the Carbon API over to Objective C with the Cocoa API set. While it would not be a huge task to convert most applications, it would leave software companies with effectively two separate code bases to manage between PC / Mac platforms.

2> Dump all the Apple frameworks (if used) and create all new application frameworks and an intermediate API interface to allow the linking of Cocoa APIs. It has been done, I know of one example of someone doing this, I can't talk about the product, sorry.

3> Just continue perpetuation of the OSX version of the software with the Carbon API and live in 32bit land forever. Or hope that Apple will ultimately dump Carbon altogether and allow for full C++ language and compiler support with Cocoa. Which would be the ideal... No one seems to know and Apple has not announced whether or not they will do this. It's clear that Carbon is to die, and Cocoa is just fine except without taking huge steps to invoke option #2 above, the only usable language is Objective C. Option #2 above is actually a serious undertaking and could break with every update to XCode. Even for large applications already written for Carbon, it would still probably be cheaper to move to option #1 -- Port the app to Obj.C / Cocoa.

We also have to consider that there appears to be no 64bit versions of CS4 anyway. And all the 64bit support that has been mentioned for Windows is nothing more than marketing fluff to say that it works under Vista64. What a pisser.

FWIW, I am not aware of any cross-platform (that's the key term here) applications that provide 64bit support on OSX. Because of the current issues. There are however 64bit apps that are OSX only, written with Cocoa, and they have GUIs.
 
Andrew said:
Dave, what final output format did you use?
Did you try H.264 for BR?
I do not have any problem with TIF or DPX.
Click to expand...

For some reason, I just lost my reply, so here goes again:
I've tried mpeg2 and H.264 both. On H.264 I selected 1920 X 1080.
Frame rate in both cases was 29.97.
I would compare the BluRay I got with any Hollywood release I have viewed so far. I would not release the mpeg2 version to anyone.

People viewing my DVDs made with the same system are telling me they have never seen any better ones commercially. I have a large collection of movies and I think I can at least match the best of them without even bothering to use CinnemaCraft to encode.
In RedCine I used Detail high, Noise reduction enabled, Quicktime, Raw, max quality, 1920 X 1080 Process full.
I don't really have any other option for use with Premier pro.
It takes about 4 days for each hour of source file to render and almost 700 Gbytes. On my computer, if I use any higher res, Premier can't play it at speed.

As for the cameras, I record at 29.97 fps 4K 16:9 with shutter at 1/96sec, 5600K lighting and F5.6. I have given up some DOF that I would rather keep to get less motion smear.

I hope that answers your questions. Fortunately, I am not going film out, so I don't have to use 24fps and have all the 3-2 pull down problems.
I wish I could record at 60fps to reduce motion smear further and make 1080P 60 BluRays, but obviously that's not possible for several reasons, yet.
(I wonder if CS4 has better BluRay options.)
Dave
 
Dave, didn’t play with CS4 Encore yet to make any BR on CS4.
Thanks for detailed explanation.
Are you outputting to BR from PR or you use Encore?
What setting are you using? What color space?
And I tried all and every color space out there possible that Encore or PR will support in effects menu.
Converting from one color space to the other should remove the banding but I don’t know how to do it. Which color space to use as a working color space and which as an output color space.

I use maximum color depth that defaults to 8 bit with anything that goes to BR.
Even if I find 14 bit codec BR player will play only 8.
I have a lot of bending on the blue sky when changing exposure.
Try to shoot it and change exposure +- two stops.
Then add some contrast or change color a bit.
Now I learn how to shoot to avoid it but then I have a lot of work with secondary CC.

What a nightmare. I rather DI to film prints than BR. BR have to go 16 bit or otherwise quality will be where it is, consumer grade.
 
Jeff Kilgroe said:
Hey, I was just picking a nit -- you said that you couldn't have an interface on a 64bit app. Not true. But if we want to analyze the situation...

Yes, as far as Tiger is concerned, the situation is pretty dire. As far as Leopard goes, it's better. BTW: that 64bit link you have there, the first one, is nearly 3 years old. There are more abilities under Leopard. Which in itself is a problem -- software developers, especially larger ones with establish customer bases, are not willing to let go of Tiger support right now. Perhaps this will change once Snow Leopard starts shipping?

The compilers are fully 64bit enabled (when compiling / linking for Leopard only), but the Carbon API is still 32bit. For now, this mean Applications built to only function under Leopard will have more options, but sill run into the limitations of the Carbon API. This leaves software developers with a couple options, none of them great. These options are:

1> Port all code base from C/C++ and the Carbon API over to Objective C with the Cocoa API set. While it would not be a huge task to convert most applications, it would leave software companies with effectively two separate code bases to manage between PC / Mac platforms.

2> Dump all the Apple frameworks (if used) and create all new application frameworks and an intermediate API interface to allow the linking of Cocoa APIs. It has been done, I know of one example of someone doing this, I can't talk about the product, sorry.

3> Just continue perpetuation of the OSX version of the software with the Carbon API and live in 32bit land forever. Or hope that Apple will ultimately dump Carbon altogether and allow for full C++ language and compiler support with Cocoa. Which would be the ideal... No one seems to know and Apple has not announced whether or not they will do this. It's clear that Carbon is to die, and Cocoa is just fine except without taking huge steps to invoke option #2 above, the only usable language is Objective C. Option #2 above is actually a serious undertaking and could break with every update to XCode. Even for large applications already written for Carbon, it would still probably be cheaper to move to option #1 -- Port the app to Obj.C / Cocoa.

We also have to consider that there appears to be no 64bit versions of CS4 anyway. And all the 64bit support that has been mentioned for Windows is nothing more than marketing fluff to say that it works under Vista64. What a pisser.

FWIW, I am not aware of any cross-platform (that's the key term here) applications that provide 64bit support on OSX. Because of the current issues. There are however 64bit apps that are OSX only, written with Cocoa, and they have GUIs.
Click to expand...

clear as crystal....
more complicated than I realized...

it does seem that photoshop extended is 64bit though, but none of the rest....
 
Can anyone with Premiere Pro CS4 check to see if it can ingest RAW files (.CR2, for example) using the Camera Raw interface? In CS3, After Effects and Photoshop can obviously ingest RAW files, but Premiere never has been able to, and I was hoping CS4 might do it (especially after all the emails I sent Adobe :wink: ).
 
That's cool if Photoshop Extended is 64bit. At least it's a start. I'd like to know about the camera RAW ingest in Premiere as well. I plan to upgrade to CS4, but I'm in no hurry and will probably wait until the R3D plugin is available and working reliably with audio support.
 
Andrew said:
Dave, didn’t play with CS4 Encore yet to make any BR on CS4.
Thanks for detailed explanation.
Are you outputting to BR from PR or you use Encore?
What setting are you using? What color space?
And I tried all and every color space out there possible that Encore or PR will support in effects menu.
Converting from one color space to the other should remove the banding but I don’t know how to do it. Which color space to use as a working color space and which as an output color space.

I use maximum color depth that defaults to 8 bit with anything that goes to BR.
Even if I find 14 bit codec BR player will play only 8.
I have a lot of bending on the blue sky when changing exposure.
Try to shoot it and change exposure +- two stops.
Then add some contrast or change color a bit.
Now I learn how to shoot to avoid it but then I have a lot of work with secondary CC.

What a nightmare. I rather DI to film prints than BR. BR have to go 16 bit or otherwise quality will be where it is, consumer grade.
Click to expand...

I used the "export to Encore" function in Premier Pro and selected the settings I listed earlier.
I don't have much time right now, but what I am getting on BR certainly doesn't look like 8 bit to me. Are you using HDMI interfaces? Component video will give you garbage.
Got to go, sorry.
Dave
 
Jeff Kilgroe said:
That's cool if Photoshop Extended is 64bit. At least it's a start. I'd like to know about the camera RAW ingest in Premiere as well. I plan to upgrade to CS4, but I'm in no hurry and will probably wait until the R3D plugin is available and working reliably with audio support.
Click to expand...

It is beneficial to run AE CS4 with a 64 bit OS (including Vista x64 which is what I'm using). I've got 8 GB of RAM installed and I can set AE to use 7.75 GB of that RAM. The multicore changes alone make the upgrade worth it.

For Premiere, there are a few things that I'm sure will change within months, but right now CR2 is not supported as an import format in Premiere, unless you take it through Ae first. The processing through Adobe Media Encoder is again worth it to buy the upgrade for that feature alone.

Background rendering for Premiere is awesome, so is not having to render before going to Encore.
 
Tom said:
Can anyone with Premiere Pro CS4 check to see if it can ingest RAW files (.CR2, for example) using the Camera Raw interface? In CS3, After Effects and Photoshop can obviously ingest RAW files, but Premiere never has been able to, and I was hoping CS4 might do it (especially after all the emails I sent Adobe :wink: ).
Click to expand...

I will be happy to check this capability later today when I get back in front of a machine with PPro CS4 installed on it.

More to follow...
 
kinobairn said:
For Premiere, there are a few things that I'm sure will change within months, but right now CR2 is not supported as an import format in Premiere, unless you take it through Ae first. The processing through Adobe Media Encoder is again worth it to buy the upgrade for that feature alone.
Click to expand...

:nerd:

Well I will keep my fingers crossed that they add it.
 
Forgive my ignorance but can somebody explain
to me what does the 64bit next to os or vista
refers to?
'cause I'm thinking of buying a mac pro or a
macbook pro for Red and I wouldn't like
to make a mistake...
 
You must log in or register to reply here.
Back
Top