MPEG-2 Encoding.. Gamma and/or Black Level?

Hello,
I am using MegaPEG.X Pro to encode MPEG-2 from my QT files that have been output from my FCP5 sequence.
The MPEG-2 files from MegaPEG.X look much darker (deeper blacks) than the original DV Movie when viewed side by side in QT. In FCP I used the waveform to set my blacks at 0 with the CC filters. So the DV Movie output from FCP should be correct, shouldn't it? The DV levels look better than what I am seeing in the MPEG-2.
I downloaded the demo of BitVice, and when I export from BitVice (I have Luma Correction checked) the resulting MPEG-2 file is much closer to the original DV Movie.
Any input would be helpful.
Thanks,
Matt

Have you applied any filters, etc to the MegaPEG settings? Which settings did you use?
Have you been over to the digigami web site and had a hunt through the info there? Gen is really helpful and keen to solve all and any problems, it seems... you could always email him directly!

Similar Messages

Noticing black level differences on different players

I've exported a project to a ProRes422 file and then encoded it in Compressor 4 into different sizes of mpeg4 and wmv (thanks to Flip4Mac Studio Pro HD) files. When playing back these files, I've noticed something strange.
This may be to be expected to those of you who are more experienced. But I noticed that when I play back these files (which are all encoded from the same master file) on my iMac (using the same screen), the files have noticeably different black levels depending on which player I'm using to play them back. For instance, the wmv files look a bit overexposed with low black levels when played back on Flip4Mac. But, play that same file in MPEG Streamclip, and the black levels are really too high.
It's not as true of the MPEG4 versions. Playing the MPEG4 version on Flip4Mac, it looks good. The same is true of Quicktime. But play the MPEG4 version on MPEG Streamclip, and it is really too dark.
Why is this? My concern is how do I know how the files are going to look to people who view them on their own devices?
Do you guys find the same issue? What do you do about it?

I've replied mainly to bump you to the top of the list again.
I wouldn't worry too much about how other people view your movies as you have no control over them and many watch them on rubbish computers.
Frequently I have posted high quality videos only to have people watch them on appallingly bad computer screens and with slow broadband creating jerky playback.
It would be useful if you could post brief snippets of your videos so that we can see exactly how much the quality varies.

Black Levels in MPEG-2 files

This is a problem I've been trying to solve for months. Whenever I encode an MPEG-2 file, regardless of what program I'm using (After Effects CS3, Sorensen Squeeze, among others), the black levels are milky grey, not black. This is a short film originally shot on 35mm; it is now a 10-bit DPX log sequence. The footage looks great in After Effects - black levels are all correct. When I export a QuickTime file from it, it looks good. But if I encode an MPEG-2 file, either directly from After Effects or using a different encoder, the blacks turn milky grey and the contrast/gamma in general just look a little off.
Any insight anyone has into this problem would be greatly appreciated.
Win XP/Intel Quad Core/4GB Ram

It's a combination of the two, most likely. In general you will want to work in vanilla sRGB or 601/ Rec 709 when preparing content for DVD to be able to predict the colors as they will go on DVD. Other color profiles will use a different Gamma, which ultimately will result in a completely different effective output upon render than the one you may be seeing in your composition based on the workspace profile and log/lin conversion. This is especially critical with outputs via Adobe Media Encoder, image sequences or certain Quicktme flavors, all of which are aware of color profiles and in part allow embedding that info. A short way to bypass some of your issues may be the "preserve RGB" option on the output module color management tab, though it may cause your video to look over-saturated. Ultimately you will probably have to derive a dedicated DVD version of your project or base the actual MPEG-II transcode on a pre-rendered, color managed file. As an last item, make sure to check your monitor's Gamma and review the final output on a real TV and DVD player.
Mylenium

Encoding to Blu-ray is destroying my black levels - what am I doing wrong?

I need to burn a short to Blu-ray for a screening coming up, but every time Premiere/Encoder/Encore finishes the disc, the black levels look nothing like what I saw in my project timeline OR in Encore's preview window. The blacks are soft, grey, with way too much detail in them. Research has led me to believe that my issue has something to do with the color values of my project going from 0-255, but that Adobe Media Encoder will automatically shift that to 16-235. Or something. I don't know, all of this is new to me in the last 12 hours.
I did miss around with the Levels effect in Premiere just to test this hypothesis, and when I bumped the black output levels from 0 to 16 in the timeline, it did replicate the difference that I was seeing in finished blu's.
I've scoured all the settings in Premiere and Encore for a way to control the black levels going into/coming out of Encoder, but cannot find anything. Someone please tell me what stupid thing I overlooked so I can make this movie look right.
For reference, my source video is:
DSLR .mov footage, 1920x1080, 23.976
And I'm exporting to Blu-ray using the following settings:
MPEG 2 (also tried H.264, same result)
NTSC
CBR (movie's only 22 minutes), but I've also tried VBR 2pass at 40mbps max, 35mbs target, and 25mbps minimum.
Profile: 5.0
Max render quality, maximum bit depth, max everything.
Running Premiere Pro Cs5.5

S.A. Hudson wrote:
...Research has led me to believe that my issue has something to do with the color values of my project going from 0-255, but that Adobe Media Encoder will automatically shift that to 16-235. Or something. I don't know, all of this is new to me in the last 12 hours.
I did miss around with the Levels effect in Premiere just to test this hypothesis, and when I bumped the black output levels from 0 to 16 in the timeline, it did replicate the difference that I was seeing in finished blu's.
I've scoured all the settings in Premiere and Encore for a way to control the black levels going into/coming out of Encoder, but cannot find anything. Someone please tell me what stupid thing I overlooked so I can make this movie look right.
For reference, my source video is:
DSLR .mov footage, 1920x1080, 23.976
And I'm exporting to Blu-ray using the following settings:
MPEG 2 (also tried H.264, same result)
NTSC
CBR (movie's only 22 minutes), but I've also tried VBR 2pass at 40mbps max, 35mbs target, and 25mbps minimum.
Profile: 5.0
Max render quality, maximum bit depth, max everything.
Running Premiere Pro Cs5.5
You are correct. Depending on a host of technical factors (none of which are visible or controllable in the GUI) the raw footage that is sent from Premiere to AME for encode can be in the range 0-255 (PC) or 16-235 (TV). Rendering at Max Render Quality should have it come in as 16-235 always.
If you encode for TV the encoder will scale the range down - making it less contrasty - ie what you're seeing) or simply clamp the values so that anything below 16 is clamped to 16 and above 235 is clamped to 235.
You said that you have your TV connected to the PC via HDMI. Can you put the reference monitor on that display and confirm that the blacks are the same as the video seen inside PPro? If so your TV is configured correctly.
Next use the 3 way color corrector (NOT "Levels" or "Brightness and Contrast" - they are clamped to the 16-235 range!!!!) to blow the image out from 16-235 to full range (check in the vectorscope or YCrCb waveform to confirm it's full range - ie WAY past the 100% squares in the vectorscope).
Check on the TV and it should not show the greater gammut. If it does it means that your TV is doing full-range.
this is all a bit late for your showing but I hope it can help.
Anyhow off that tangent...
I would recommend you export a h.264 clip to a usb stick if your standard home-use blu-ray player has usb stick playback.
Put that stick in your blu-ray player or Samsung TV if it can do it too, and see if it'll play back with the right blacks.

Black levels and exporting

Hey there-
When I export anything through render cue using Lossless, Lossless with alpha or Custom Quicktime the black levels of the rendered file are 5-10 units high regardless of the program that I use to open it. I'm exporting to a local hard drive and not a server. I'm using After Effects CS6 and Final Cut Pro 7.0.3 on a Mac. The export settings in After Effects are the same as others in my office and no one else seems to have this problem.
Thanks for your time.

By “units” I mean pedestal units on a wave form monitor. Final Cut has a wave form/vector scope feature. The apps that I use do not have features to adjust gamma, video levels or pedestal. I'm not using color management. I've tried importing raw video (uncompressed Sony XPCAM) and Quicktime files from different sources, adding them to the timeline and exporting them without applying anything at all. The codecs that the files are being exported to are animation and timecode. As far as monitor calibration, everything with the exception of exported After Effects files looks normal in Final Cut Pro. (blacks have definition but are not washed out, whites and colors look normal). Could it possibly have something to do with how the files are being imported?

Encoding Menus - without re-encoding imported (and already encoded) mpegs

I uncerstand that its best to encode Video with Compressor and Audio with A-Pack - but once you've done that and imported the resultant .mv2 and .aac into DVDSP, its now time to compile the menus, buttons - basically the entire disc.
Well doesn't that then force DVDSP to re-encode all those already-encoded video and audio tracks?
I mean I don't get it, how can you compile/build the disc without hurting your Compressor-encoded files?
Or do you just skip the "build" and go directly to "format"?
MacBook 1 gig RAM Mac OS X (10.4.9)

Ok, not that I doubt you, but, well, how do I know
that???
Take a look at PG 230 regarding the menu issue, also
take a look at page 66 for some info.
Unfortunately, I'm on the road and don't have any of my manuals handy. Just my macbook and a 500gig hard drive.
Either way, I think I figured this whole thing out. I made a new folder, created a totally new project, encoded all my video files with Compressor and the audio with A.PACK and put everything in that new folder. Then I set-up the menus, buttons, links - everything - and did a "build" - Its very clear that DVDSP didn't touch any of the encoded files. I saw that an "mpeg" folder was created inside the new folder I had just created - but that's because of one of the template motion-menus I used in the project. Everything else stayed as is.
So, this proves beyond any doubt that building/muxing doesn't harm or re-encode previously encoded assets.
If the video is long,
or you made complicated menus or are using
transitions (which are encoded/made by DVD SP) then
things can take a good chunk of time.
I didn't know transitions slowed things down - but this totally makes sense.
as an aside, are you running the Universal Binary of
DVD SP?
Oh - I'm running version 3 of DVDSP - not up to version 4 yet - and I'm running it on a brand-new black macbook... I think this combination might be causing some problems.
Either way, things are looking pretty good right now. I haven't burned a DVD yet - which is the final test obviously - and that's coming next - but things are looking good so far. I'll know the bottom line to all this very shortly and will let you know how it went.
In the meantime, thanks a lot! I very much appreciate your assistance.
I'll probably have a Compressor question next
I'm not crazy about the quality of the image that I got by encoding with Compressor. DVDSP did it better - but that's a whole other thing - are you able to answer Q's on Compressor?

OpenGL inaccuracies and black levels

Here is an sRGB file consisting of 0,0,0 background, with five overlaid squares at one level increments, from 1 to 5.
On my Eizo CG246, calibrated with Eizo ColorNavigator, all five squares are discernible against the black background, as long as Graphics Processor > Advanced is set to "Basic" mode. This means that the color management logic (the conversion to the display profile) is performed in the CPU.
In "Normal" and "Advanced" modes, color management is shifted to the GPU. With these settings, black levels disappear. It's not dramatic, but it's there. The difference can be illustrated in a screenshot, as long as the display profile is assigned and the screenshot is pasted in the Basic mode. Here's how it looks straight up (should be viewed against a dark background):
Here I put a Curves layer on top to exaggerate:
And here I read out the numbers from this exaggerated version:
So far it seems this can not be reproduced on another monitor I have, an NEC P232W calibrated with Spectraview II. It also seemed a bit more pronounced on a different Eizo I no longer use, an S2243W, calibrated with Eizo EasyPix.
This suggests that the problem is in the interaction between the display profile and the Open GL engine that does the conversion. I think this is related to the ProPhoto cyan banding issue previously reported, because that also seems to behave differently between these two systems (I'll do some more testing on that).
In all cases and all scenarios, all irregularities disappear with Open GL in the "Basic" setting.

You neglected to include your test image with black and levels (1,1,1) through (5,5,5), but no matter, I have the one I made...
http://Noel.ProDigitalSoftware.com/ForumPosts/DarkGrayColorLevels16Bit.png
I've found that here I'm not seeing a visible difference between GPU and CPU color-management with the image in the sRGB color space. In other words, no crush. With the image in the ProPhoto RGB color space, some slight crush was apparent, along with color shifts almost exclusively toward red.
However, that's not to say there are no differences between the two. They're just more subtle than what you're seeing. What I did to test was this:
Open the image I linked to above using Advanced mode OpenGL.
Float it in a window.
Screen grab it.
Pick it up and start to drag it.
While still dragging, screen grab it again.
Overlay the two images, and pixel align them.
Set the top image to "Difference" blending.
Add a couple of Curves layers over the top to greatly enhance the differences to make them more visible.
Since my test image has a dark grayscale gradient expressed in 16 bits/channel, it's not only testing for accuracy at the visible level, but also for very subtle changes. Lo and behold, changes are revealed. Note:
Enhanced differences between GPU and CPU rendering of the image in the sRGB color space:
Assigning the ProPhoto RGB color space to my test image, then comparing GPU vs. CPU rendering...
-Noel

Same MPEG-2 encoder in AME and Squeeze?

Can anyone tell me if the Mainconcept MPEG-2 encoder used in AME CS 5.5 is the same encoder as the MPEG-2 encoder in Squeeze 8?
I'm evaluating Squeeze, more or less, to see if helps produce a better DVD from an HD project.
Thanks...Ben

Apple doesn't want users to export using the MPEG-2 exporter any longer.
The new video editing suite of apps includes Compressor which is what you should use.
The older method will still work but may require you to re-install DVD Studio Pro.
You may also need to update the MPEG-2 Playback Component. Current version is 6.4.

Data below black level 0 in h264 mp4 files.

I'm a little confused about black and white levels in video.
I have two questions. If you bare with me for a second I can demonstrate what I mean.
I created gradient with values from 0,0,0 to 255,255,255 in Photoshop and saved it as sRGB jpg file.
I imported the file to Premiere and added Fast Color Corrector to the file and changed black input level from 0,0 to 16,0
So now everything below value 16 is cutted to black.
I exported the edited gradient as h264 mp4 videofile.
Now things got interesting.
I imported the edited videofile back to Premiere, added Fast Color Corrector to videofile and changed black output level from 0,0 to 16,0
The information that I thought was lost is there!
I tried to to the same thing for the same video file with Photoshop and I'm not able to get the lost information back.
Why is there information below 0? And how am I able to rescue it with Premiere, but not with Photoshop?
Does this have something to do with YCbCr black and white levels that are 16-235?
This whole question came up when I calibrated my Samsung lcd-tv. I used AVS HD 709 mp4-calibration videos.
There are black level calibration videofile. Which is exactly like my gradient video file where there are black values below 0.
If you lift your tv's brightness below certain levels you are able to see the black values that are below 0.
I'm able to see these "blacker than black" values with tv's own videoplayer and with xbox videoplayer.
However, if I try to see these values with my macbook pro which is connected to tv I can't get them visible.
It doesn't matter if I play the video with quicktime, vlc or premiere.
So the second question is why the macbook pro does not send any "below black" information to tv?
PS. I'm using latest premiere CC.
Thank you in advance!
In this image you can see from Premiere Scopes what is happening.

Does this have something to do with YCbCr black and white levels that are 16-235?
No and yes.
When you manipulate levels values within 0-255 (0.0-1.0) range, you don't clip existing data, you simply compress/decompress contrast, while information is still there (to some extent). By the way, data outside 16-235 range, but inside 0-255 are not super-blacks or super-whites (underdarks or ovebrights), they are just broadcast safe values. Super-blacks or underdarks are values below 0.0, while super-whites or overbrights are values above 1.0. The nature of YCbCr does allow to store some real super-blacks and super-whites even while encoding to 8-bit codec.
Why only some codecs are able to preserve this "illegal" values?
MOV container is... um-m-m... quirky. For example, exactly the same data encoded to e.g. mp4 and MOV with exactly the same codec (e.g. H.264), may be decoded/interpretted differently. So as to have some fun, create a copy of an mp4 clip, which contains some super-whites, rename file extension of one copy to MOV, import both mp4 and fake MOV footages into After Effects, set your project to 32-bit, sRGB or Rec.709 and linearise working space in order to get precise result while blending layers. Then drop both clips into the same composition and set blending mode to Difference. Enjoy!
Why I'm only able to access these values inside Premiere and not with Photoshop. Is Photoshop unable to access these illegal below 0 values?
Try setting Photoshop to 32-bit first. If that doesn't help, then yes, Photoshop clips values outside 0-255 (0.0-1.0) range on importing. Similarly you won't be able to get super-whites or super-blacks back in PrPro with 8-bit effects.
When i export with codecs that can preserve superblacks should I still get rid of them with videolimiter. Do they cause any problems in youtube or broadcast environments?
No. Moreover, you should take care of broadcast legal range in case of delivering to a broadcaster only, YouTube 'broadcasts' on the web and targets regular computer monitors, which operate on sRGB 0-255 range.
why the macbook pro does not send any "below black" information to tv?
That has probably something to do with Apple colour management workflow. Since I'm not on a Mac, I can't comment this on

Black Levels Boosted Upon DVD Burn

I realize this topic has been covered and have read the many threads on this and on other forums. I have used the FCP forum in the past and thank anyone who has ever helped, well, anyone with a question. The link to purchase a Proc Amp is wonderfully informative and does nothing to remedy the problem or answer the question (for under $700).
Is the workaround (yes, yet another workaround to add to the incredible list of hoop jumping - try using Soundtack Pro to alter audio clips not captured in stereo!) really to figure out a final "DVD export" setting that compensates for the black level increase? That's what I've gathered after a couple days of casual research and all today really trying to tackle the problem. Sorry, just a little frustrated.
If anyone was patient enough to read this all the way through and has a better idea than dropping the video level before exporting to Compressor/Quicktime please let me know.
Also, why is the problem not nearly as noticable in my three year old version of iDVD?
G4 Dual 1.25, 2GB RAM Mac OS X (10.3.9) FCP5.03 DVDSP4.03

When you say "black levels boosted," do you mean you have too much black or not enough black? In other words, is your complaint that things are too dark, or that blacks are no longer "true" black?
From your text, it sounds like you're complaining that your footage is too dark.
Most complaints, however, are that compared to DV footage, the MPEG2 results are washed out. This is because they're comparing footage that has no "setup" (i.e. playing video directly out of the DV camera) with footage that has "setup" (i.e. playing video from a DVD player, which defaults to black equalling 7.5 IRE rather than 0 IRE). This is why you've seen the "proc amp" recommendation elsewhere.
Can you describe your workflow in detail? It sounds like you're probably using DV footage--is that true? Are you exporting out of FCP into Compressor directly? Exporting a reference movie first? Exporting a movie and then encoding from QuickTime? Other?

Black level too high after calibration

I calibrate my MBP's display (MB470) using Monaco Optix XR. I tried EZ Color and ColorEyes software to create profiles. The result is pretty good in both applications, but both create profiles with lifted black level.
It's much noticable when looking at dark underexposured photos: shadows are 'posterized'.
So. With native MBP profile (Color LCD) shadows are more accurate, but colors are a bit shifted. Calibrated profiles are good at colors, but bad at shadows.
Anybody got good results at calibrating?

Hey Drew,
Gotcha, I just realized it must be fixing something with markers. I haven't had a problem with that yet though, fortunately. I've been exporting directly out of FCP using Compressor, so there's no intermediate file. Like I said, the encoded ac3 sounds perfect, so it seems like it's something happening in DVDSP. Do you know of anything in that program that might have caused this? If it makes any difference, I burned the disc by simply hitting the "burn" button rather than building. Could that cause this sort of thing?
Cameron

Black level problem with H.264 (Windows)

I have a Windows 7 64, latest version of apps. I have a reproducible problem with sending AE comps to AME - the black levels get shifted from 0 to 254 to 16-235. Only a problem with H.264 specific preset. If I chose QuickTime and H.264 there, works fine. I have Main Concept H.264 encoder to available to me in Sony Vegas, it also works fine.
Can't seem to find any info on this.

thanks David.
can anyone out there on an intel mac check these?
i have a hunch this is an intel thing.
here are the links again---
http://www.de-edit.com/snp_teafield.html
http://www.de-edit.com/snp_wiseman.html
http://www.de-edit.com/dsw_winterpreps.html
http://www.de-edit.com/dailynews_tollbo.html
just to recap--they become black about 1-2 secs
into the spots for a few seconds. it's kindof at the spot where the
downloading is catching up with itself--does that make any sense? there's a
little audio glitch there as well.
thanks in advance
danny

H.264 gamma and/or color off

Anything I export as h.264 using QTPro looks washed out and the colors are off. Is there any way to tweak the export settings to correct this?

I have been spending the better part of 2 days trying to figure this out. So far I have learned that Quicktime is displaying a gamma shift in the rendered video and that the actual file is okay, it is quicktime that is messing it up. This also goes for anything that uses quicktime, like safari, itunes, and similar players that use the Core Video hardware acceleration. Computers or Players that don't use hardware acceleration will show the same file correctly when played. But of course this is still an issue for anyone viewing your video on another computer with hardware acceleration enabled. To them your video will look faded.
It happens far worse on windows machines where the gamma is set to 2.2 (my mac was set to 2.2 until I found this nasty H.264 bug in quicktime rendering.) In the 2.2 gamma environment the shift in brightness is very pronounced. In the 1.8 mac gamma environment, it is less pronounced but still problematic enough that many of the studios that I know won't use Quicktime or the H.264 codec until this bug is corrected.
This problem is documented all over the web and it has caused major headaches for a lot of people for somewhere around 3 years. So far Apple hasn't done anything to fix it (or can't fix it) even though it is a persistent problem, especially for people who calibrate their monitors or people on PC's.
It's really frustrating and after hours of scouring the net for an acceptable solution, I still haven't found anything that doesn't involve simply not using quicktime or h.264. Here is one (partial) solution I found:
+This tip from Mitch Gates:+
+As you may have noticed, the current implementation of the H.264 compressor for Quicktime has the nasty side-effect of raising the gamma or black levels of the resulting movie file. In order to fix this you must have Quicktime Pro (otherwise the fix will not hold since you can't save the updated .mov). Here are the steps?+
+Open the QT+
+Go to "Window/Show Movie Properties"+
+Select "Video Track", then click the "Visual Settings" tab+
+At the bottom left, change the transparency to "Blend" then move the slider to 100+
+Change the transparency to "Straight Alpha"+
+Close the Movie Properties window, then play or scrub the QT. Your black levels should now look correct+
+Save over old .mov+
This is for PC's. On the mac you change the transparency to "composition."
The problem with this solution however is that doing this disables the settings that allow fast playback (playing the movie before it is completely downloaded.) Another issue with this solution is that, while it fixes the look of the video in Quicktime, VLC player still exhibits the 'washed out' look on the same file. Finally, this "solution" isn't actually a solution at all.
An interesting thing about this is that the video file itself is not really washed out as far as I can tell. There are a few things that point to this. One, exporting the h.264 file and changing the codec to "Animation" or "None" corrects the gamma shift and returns the colors to where they should be, but this increases file size dramatically. Second, I noticed that when I select the h.264 file and choose "get info" the preview thumbnail shows the poster frame with correct colors. Third, when I put the h.264 file online Safari shows it all washed out but FireFox shows it correctly. Strange...
At this point I think the only viable solution is to do this:
+MacInTouch Reader+
+I too have been plagued by this H264 problem for the past 2 years it seems.+
+I have a suspicion that if we polled the users experiencing this effect that it would result they all use custom or modified Display Profiles in the Display System Preferences.+
+My temporary (and somewhat silly workaround) has been to change my display profile to the standard "Cinema HD Display" instead of my user-created "Cinema HD Display Calibrated" profile.+
+It does alter the gamma of my display to a unpleasing value, but after changing it, the H264 export works beautifully. No gamma shift at all.+
+I have read all the suggestions on trying the quicktime "filter then colorsync" export and always got unsatisfactory results. My silly workaround always produces the best results. I just have to change the dang setting back after I export so my eye don't burn out of my skull.+
So it all comes down to a gamma shift on the part of Quicktime's render of H.264. You would think that after so many years of this issue going on Apple would have fixed it since they have documented that they know of the problem. A little baffling.
If you want to research this further, as I will continue to, just type "h.264 gamma" into google and you will find a ton of fellow frustrated users trying to figure this out. Most just switch to Sorenson 3 it seems or "un-calibrate" their displays when doing the render export. None of this is perfect unfortunately and I find myself using "Animation" even though the file size is insanely huge. It is better that having upset clients telling me that the video is washed out.

Compressor 2 black level/chroma issue

I have discovered a problem about making MPEG2s with Compressor 2. I have two suites one of which has recently been upgraded to FCP Studio with Tiger; I used Compressor 2 to make a batch of MPEG2s and some QTs for the web. The QTs were fine but the MPEGs were oversaturated and had crushed blacks. I have tried both the new and old setting and the problem is common to both. I have tried recompressing material that I already have MPEGs of that were made with FCP 4.5 and Compressor 1. The new ones are different and all exhibit high chroma low black levels.
Since my second suite is still running FCP 4.5 and compressor I ran the same tests in the old suite and the levels looked fine, suggesting that there is an issue with Compressor 2.
I tried to alert Apple directly and was told that they had no way of putting me in touch with anyone directly. So I hope that for the sake of other users and myself this posting will ring some alarm bells.
Robb Hart
an ideal world
714-953-9501
[email protected]

Let me be clear, I am not seeing any significant differences in the black levels and colors between Compressor 1.2.1 and Compressor 2.0.1 and yes I am using the same decoder when I compare the clips (Apple's MPEG2 Playback component). I've compared the clips side-by-side on the same display under both OS X 10.3.8 and 10.4.2. However, I haven't done an extensive set of comparison with a wide range of source material (at least not in any detailed manner).
As for being CoreImage accelerated, under 10.4.X I do have support for CoreImage functions but they are not GPU hardware accelerated. Thus under 10.4.2 I do not get QuickTime's realtime color corrections. My PowerBook also supports Quartz Extreme.
However, if you're talking about the so-called Quartz 2D Extreme then my system doesn't support such acceleration (and as far as I know Q2DE isn't even enabled yet -- not on any system -- you need a developer debug tool to turn it on).

Advice needed on white imac 24" screen - black levels

Hi, I'm new to these forums as I'm a new mac user. So far the experience has been pretty good!
I have a white 24" imac, and the colours and black levels look pretty ok in a normally lit room.
However when I turn the lights off (room is in the dark) and view say a black screensaver, the whole screen appears greyish rather than a pure black. The greys appear quite even though, no splotches or anything.
Is this something I should expect, especially for the iMac screen which is known to be an IPS lcd panel? Or should I give apply a call about it?
Any advice and help would be greatly appreciated, thanks!

More than likely that is caused by the backlight and is normal.

MPEG-2 Encoding.. Gamma and/or Black Level?

Similar Messages

Maybe you are looking for