No compression QT conversion w/Color Shift

Hi,
I have dpx files that I make an uncompressed QT of (from shake).
When I convert this qt to a uncompressed 422 qt via qt pro, I get a color shift (visually and in histogram).
Yet when I do it thru shake I don't.
Even in Nuke I get color shifts.
Is making a video qt from a rgb file better off done thru hardware video cards?
Thanks for any help.
Tom

Sorry mate have no idea with PC's, hope someone will see this.

Similar Messages

PLEASE HELP - COLOR SHIFTING PROBLEM on output NTSC monitors

http://www.smmlv.com/testproject/
Above is a link to a layered photoshop file that has a USA map and over a dozen network overlays used in a section of our video. I animate each layer on sepeartely in the video and have noticed a major problem recently, the color of the art does not hold true to placement. I created the art originally in Illustrator and then converted the file to Photoshop at 640x480, 72dpi. This has always worked perfectly in the past to display and animated artwork in FCP.
Right now, in FCP I am using the NTSC DV 3:2 frame size, and the compressor of DV/DVCPRO - NTSC. I have a JVC Profressional DV deck that hooks up through firewire and sends S-Video to my monitors. This setup has always given me a great picture even though it is not completely upcompressed. Using these settings and this art, the color lines on this map in red, light blue, yellow and purple all have a "color shift" to the left about 5 pixels. It makes it appear that the line is where it is in the file, but the color overlaying the line is offset to the left 5 pixels and transperant to about 50%. This occurs only when viewed on some TV's and NTSC monitors and projectors. The strange thing is, some monitors display the color aligned almost perfectly on these maps and other monitors and projectors show this "digital halo" of color shifting really bad. If I take the layered network overlays in these colors and color tint them to black or grey, white, light green, or even light orange, they no longer have the color shifting and the detail is perfect.
Is there any way to fix this problem? I have tried duplicating the sequence and setting the compressor to 8bit Uncompressed, and while my captured footage is not this compression, in theory the art should render at this higher resolution setting. This did nothing to solve the problem.
I also have tried using different Broadcast safe and Y/C corrector filters with different results. The Y/C filter allowed me to reposition the color problem and thus removing most of the problem, but also removing most of the color. Nothing else has allowed me to seemingly move the color into the proper possition.
What is causing this color shift on the displayed NTSC image?
In FCP 4.5 I can see my rendered video in the program viewer screen and besides the pixel compression appearing on the lines, overall the video looks great paused or even better when playing. Then you view it through my deck onto my Pro Sony NTSC 19" color monitor and it also appears great, with a slight color halo to the left of these colors, but the color in the lines are there. If you are a few feet from the screen and know what you are looking for you might see it, but doubtful. Then you view it using the same signal on a 17" Samsung TV and the color shifting makes the map and other art, like the clients blue logo, look horrible, with each color line appearing twice and offset left from each other as if you had double vision. Normally I would think it is the TV causing this, but then we tested this same movie on 2 differnt projectors. The $700 Epson projector displayed everything beautifully, again with only the slightest color halo to the left, but then the Panasonic $4000 projector made everthing in these colors look double vision again. What is going on???
One more thing to keep in mind, my color bars also show this problem with these colors as well as shot footage of these facilities. There are tall red poles in the shots and everything displays fine except for the red pole color looks like it's glowing off the pole to the left.
PLEASE tell me there is a solution to this.

I have tried Degaussing, using filters, changing cables, and testing other monitors and systems on these monitors, everthing I can think of to solve the issue. Is it FCPo or is it the monitors?... or is it a signal strength thing. Can monitors and projectors shift color when the signal is read from a DVD or Mini DV Deck? Is there a fequency difference (Ie: 75mgz or 80 mgz) that might be causing the shift in some monitors and not so badly in others. But if this was true, how would some DVD's (like Baby Einstein DVDs that use really bright colors) display red and blue perfect using these same player and monitor, while my projects is shifting color? Doesn't that rule out the signal from the DVD player if other DVD's do not have this issue?
I have uploaded the original art used, an exported .jpg file from the FCP timeline and sample photos of 2 different monitors to show to show this problem as best I can. http://www.smmlv.com/testproject/
Someone out there must have had this problem before. There's no way a color shift problem like this with Mini DV has gone on this long without someone seeing it.
One last thing about what I have tried... I do understand that with editing in Mini DV instead of uncompressed or HD video I lose a bit of resolution (4:2:2) and I see this compression occuring in some of the areas in the video where these problems persist. But, I did remake the art and rerender this project in an 8bit uncompressed settings and then displayed that up on the screen and I get the same color shift. I keep going in circles trying to find the culprit that is causing the delema.
PLEASE HELP! There are large tours going through our facilities daily and the large screen projector is displaying this problem as well. Let's just hope they don't notice and that their TV's at home or office does not display it on our final DVD's made.

QuickTime 7.1.6 Gamma/Color Shift Is Demonstrable

You can easily see the undesirable behavior of gamma/color shifting when playing H.264 codec movies in Apple's QuickTime Player.
Download any Apple HD (1920x?) QuickTime Trailer. Open and switch view to Double Size. The movie will immediately become darker with a pronounced gamma and color shift.
Reopening the movie switches back to the correct gamma and color.
I reported this bug, and since it's so easy to demonstrate, Apple should be able to fix it once and for all.
PowerBook G4 17 Mac OS X (10.4.9) QuickTime 7.1.6
PowerBook G4 17

I think you may find some will argue with you. DV and H264 at normal size look too bright and washed out for a lot of people, and are not the correct amount of darkness they should be. Fortuately when they're compressed to MPEG-2, if that's where you headed, they get the contrast back again.
Playing the move doubled up is one of many work arounds to the problem. But the problem isn't the one you think it is. You're right about the fact that it should be fixed once and for all.

Solution to Gamma/Color Shift Problems with Apple Codecs - Adobe BUG

Hi....
In AfterEffects when choosing an output module and that module be ProRes or 10 Bit Uncompressed,
when trying to color manage the file, there is a fine line called
'This Codec Does Not Support Output Profile'
You can find it int he Color Management Pane of the output module....
Funny thing is - That Profile Embedding IS support by:#
Apple's Compressor and THE CODEC 4444 AND UnCompressed
Episodes Encoder
See following Screen Shots:
First one from Apple's Compressor...
Look at that little beautiful Color Option... Adobe did you MISS that one, perhaps...
You must have - because your APPS are NOT including that when encoding or should I say
butchering movie files....
Here adobes famous but wrong dialog!!!!
And in this next screen shot you can easily see that adobe just strips the color profile out of the file...
AND THAT IS WHY THERE IS A COLOR SHIFT...........
left image = Apple's Compressor Encoding (Colors match of course) - Right Adobe's BRUTAL encoding (Colors WONT match...)
Now, in after effects you wont notice the shift. But ALL mac and PC users using quicktime to watch YOUR movies
are going to be looking at a movie with a different look than you thought it WOULD be... Courtesy of adobe ;-)
Jokes aside, Adobe.... It seems as if this one is on you to fix... Apple's Compressor has NO problems. And other encoders are also preserving those values.
Now... Let us assume that I encode in compressor... Looks are matching 100% that of the original source. All it takes to mess that up is ONE
roundtrip to after effects, premiere pro or Media Encoder. That is if I wanna maintain my initial choice of transcodec - in my case 4444 or 10bit Uncomp.
I could of course export to animation and then use compressor AGAIN to transcode to my format of choice... But in the long run I think that will become tedious.
Perhaps you could assign a few engineers on this one and in the future spend MORE time on living up to the name PRO(The most misused word in the software business) instead of wasting time generating new Application icons for your apps....
Thanks for reading and for a PROMPT and near-future BUG FIX

Mylenium wrote:
It's not really "embedding" anything, it merely sets the QT color space flags which have been there forever, but are mostly unused. Specific to ProRes it also toggles different internal optimizations in the encoding. That's also documented somewhere on the QT developer pages. I'm not sure I share your views otherwise. The point really is, that Apple developed ProRes just as much as a closed workflow within their products as Avid did with their CoDecs. Therefore the widespread use of the CoDecs is merely a byproduct of the use of the products, but not per se an intended workflow outside of those and, which is the more important part, also not explicable as a causal circumstance of the quality. If I may be so bold: What you are saying sounds like everyone would be using the Animation CoDec because it is so good, when the simple fact is that there are no decent free cross-platform alternatives and people are willing to accept limitations because of that. Don't get me wrong, ProRes is well designed and pretty robust, but the world doesn't come to an end without it and outside the Mac world it is difficult to deal with. Hell, it's even difficult to deal with between different versions of FCP occasionally...
Mylenium
I have been testing codecs for a long long looooooong time. My criterion(s) are:
1) Image Quality and that through multiple encoding generations and color grading
THEEEN
a looooong way down the road
2) Performance
BTW - I find that working with files less compressed and thus HUGE is much better. Hard drives are so cheap that one can build himself an 8 Disk RAID0 and that takes care of everything. In PPRO I can cut real time in FulRes with an uncompressed codec with the processors maxing at 3% while the H264 editing sequence will stutter like a drunken wasp and maxing the CPUs at 63%.... Go figure...
ProRes 4444's impeccable imageQuality:performance ratio, is unbeaten.
Especially on H264 material like that of the Canon5D. You might say if the source is 4:2:0 why bother upping it to 4444... Well in theory perhaps
it is overkill. But rather than reading in theoretical white papers I conduct my own tests. And the end results are (REALITY) and way different from what theory states. TO anyone reading this. DONT believe ANYTHING you read about codec nor what I am saying.... DO YOUR OWN TESTING and judge for yourself. Problem is that you have to do 100's and 100's of transcodings with ONE source to various destinations with lost of grading and transcoding generation. THEN you have to keep track of your tests and THEN compare them. It takes WEEKs. But it is well worth while it. In my case... I start with a Canon5DMKII H264 movies. Transcode it to PRORES4444 then I do LOTS of compositing and re-encoding then lots of color grading etc etc etc. Then I export back to H264 - and the end result is STUNNING has NO artifacts and is adorable to look at. Not so with at least 6 other codecs claiming to be top-notch....
Sure Mylenium, the world would NOT end with PR4444 not in it... BUT the WORLD has ALREADY decided that it WANTED ProRes4444 in it. It is growing and that every day..........
Had the codec not been so darn excellent - it would NOT have been used. Period.

[FIX] Darker prints and color shifts when printing from Lightroom 2

Hi,
The problem :
When printing RAW or TIFF files from LR2, you get a printer output that
is much darker than it should be and that presents various color shifts.
I'm using an Epson Stylus Pro 3800 with the latest Windows driver
(6.50 - which is rather old by the way). The workaround described below
works for me under Windows XP SP3. It should also probably work with
other systems/printers/drivers. Use at your own (minor) risk.
The "official" procedure for printing from LR is as follows:
1. Do not let the printer manage colors and select "Other..." from the
profile dropdown list and select the ICC/ICM paper/printer profile that
you want to use.
2. Click on Print... in LR which opens the Print Settings dialog.
3. Select the options you need and the paper you're using.
4. **Disable the color management from the driver's side** (in Epson's
drivers, "Mode | Custom | No Color Adjustments").
5. Print
Unfortunately, **this doesn't work** for many of us and this produces a
print that is dark and has color shifts as mentioned above. Note that
the same image prints correctly from QImage or Photoshop CS3 (that is,
the printer output corresponds to what you see on your calibrated
display).
Apparently, although color management has been (allegedly) disabled in
the driver, there's something wrong between LR and the driver which
makes that *both* LR and the driver are still trying to manage colors.
In other words, the "No Color Adjustements" option of the driver doesn't
seem to work with LR.
The workaround (found after hours of hair pulling and paper and
expensive ink wasting):
In step #4,
1. Instead of selecting "No Color Adjustments", set Mode to "Custom |
ICM
2. Click Advanced...
3. Check "Show all profiles".
4. Select Driver ICM (Advanced)"
5. Set **both** the "Input profile" and the "Printer profile" fields to
the very same profile that you specified in LR.
That is, if you specified Pro38 PGPP (Premium Glossy Photo Paper) in LR,
then also select Pro38 PGPP in both "Input Profile" and "Printer
Profile". This has actually the same effect has disabling color
management in the driver (what "No Color Adjustements" should normally
take care of).
That's it. When printing, you'll get exactly the same color results as
when printing from QImage or Photoshop. No more dark prints. No more
color shifts.
One might think that the bug is in the Epson driver but in that case,
QImage would have the very same problem. So I tend to think that the bug
is on the Lightroom side.
Note: Although Photoshop CS3 produces a correct printer output, it
demonstrates the same problem as LR when using the "Match Print Color"
option for soft proofing. But in that case, only the preview colors are
wrong. The printer output is ok. Which also tends to demonstrate that
Adobe has the problem, not Epson. Or maybe both... :-) .
Don't ask me why some users have the problem and other don't.
Hope this helps.
Patrick Philippot
MainSoft Consulting Services
www.mainsoft.fr

A sincere thank you for your reply, Michael. Sorry about the "it just doesn't make sense" shortcut. I have been trying to solve this issue since LR 1.1, spending dozens of hours on different trials and digesting everything written on this forum and the B9180 forum about color management and double profiling. My shortcut was a summation of my experience (and my frustration) but doesn't really advance the conversation. Here are some data that should be more useful in diagnosing the problem.
I am running Windows XP SP2. I calibrate my monitor monthly with the Spyder. The reason I suspect this may be an issue of double profiling is because the results (moderately strong magenta overlay plus an increase in contrast) match what more knowledgeable people than I on this forum describe when double profiling occurs. Perhaps I shouldn't presume it is double profiling, and follow Patrick Philippot's lead in naming the problem "color shifts." Patrick does refer in post #2 of this thread, however, to obvious double profiling.
I certainly do have a successful and consistent print method. With PS CS3, and either my Epson 1280 or my HP B9180, the output is almost always dead on. Here is how I do it. In PS from the print dialog box, under color handling I always choose "Photoshop manages colors." Then under printer profile I select the profile designated by the manufacturer for a particular paper/printer combination. Then in the printer driver I disable printer control of color. With the Epson I check the box "Off (No Color Adjustment)." With the B9180 I choose the option "Application Managed Colors." While I sometimes may tweak the final output, these procedures have served me well with PS for several years.
Contrasted with my positive PS experience, my experience with LR printing has been inconsistent. I regret having to be so imprecise but truly sometimes LR produces accurate results that match the calibrated monitor, but most of the time it does not. I use standard procedures with LR that parallel the PS ones described above. In LR's printing panel, under color management, I specify the correct profile, just as I did for PS. Then in the printer driver I use the same procedures I use with PS. Most of the time the prints have the magenta overlay and too much contrast.
BTW, the inconsistent LR printing only takes place with my HP B9180. I have never had any problem with off-color LR prints with my Epson 1280. Again, I emphasize that I have standard procedures that always work with PS (no matter which printer) and LR (but only with the Epson).
Unfortunately the LR printing problems are intermittent. Some of the time (perhaps 20%) LR produces fine prints in the B9180, indistinguishable from PS prints. When LR is printing well, it will continue to print fine until "something happens" and the output shows the color shift. This means I do not get a random sequence of good-bad-good-bad prints, but rather good-good-x factor-bad-bad-bad. Ths problem is that I do not know what this "x factor" is. Once, when LR was giving me accurate output, I simply changed the default printer (Control Panel-Printers and Faxes) from the B9180 to my Samsung 1430 laser; immediately afterwards the LR output colors shifted. Did LR react to this change in default printers? Another time I had good LR printing success with version 1.2 but ran into the problems described above when I upgraded to version 1.3.
Sorry for the long post. I am hoping that someone will see something that I am missing and provide a hint. I think, though, that Patrick is correct when he states, "I tend to think that the problem is with LR. After all, similar issues (obvious double profiling) are observed only in LR but with various printers."

Color shift between Library and Develop module

Hi,
I recently noticed a color shift between in the image when going from the library to the develop module. Yes, I know this is mentioned in the FAQ, but I did not find the solutions given there to be satisfactory.
Let me explain what happens: I have taken Photos with my Canon EOS 300D, in Jpeg mode with Color Space in the Camera set to AdobeRGB. The photos I am talking about were taken with Tungsten light with auto white balance and have a distinct orange color cast. I use Windows XP and view my Photos on a LCD Display calibrated with the Pantone Huey system. The Lightroom Library Module and Photoshop CS2 both display the original image almost identically (there are no changes applied inside Lightroom or Photoshop, I view the original image in both applications). Photoshop is set to use the Adobe RGB Color space as its working Color space, Softproofing is switched off. However, when I switch to the Develop Module, the colors (especially the orange hues) shift very noticably toward pink. I can only assume that the Colorspace conversion or maybe some implicit soft proof used differs between the modules. So, to restate the problem: If I switch back and forth between Library and Develop, without changing anything and in 1:1 view to avoid errors introduced by different zooming methods, the colors shift quite drastically back and forth.
I have to say that this is really quite annoying. The whole point for me to use the develop module is to use it to make adjustments to the colors, and for this to work properly I have to see the same colors in both modules and in Photoshop. There is no point in correcting a pink color cast away in Develop that is not even there in either the library module or Photoshop (and that would then have a stronger orange tint because I tried to counter the pink tint in develop).
So this leads me to the final question: Is it possible to tell Develop to use the exact same color settings as the Library Module? Or is there another way to compensate for the color shift?
I hope I was clear in what happens and what I tried to do. If it helps I can gladly provide a sample photograph that clearly illustrates the point.
Thank you in advance for your help,
Daniel

Thanks for your comments, Don and Fred. I hope that this issue will be worked on soon.
Fred, I have set the Preview Quality to High, but it doesn't seem to make any differences concerning the color shift. I have investigated this matter further by now and made the following observations:
*The color shift is a lot less noticable on my laptop (the laptop screen is also color profiled). On my laptop the change is more of a subtle shift in contrast than in color. This might be caused by the smaller color gammut of my laptop display though.
*I have uploaded a testimage so that others can check if this shift occurs at their workstations too - after all, it might be a misconfiguration of my color management software, though I doubt that (because Adobe already states that library and develop render different previews). I would be interested if the color shift I describe is noticable at other workstations too. The link to the testimage: http://www.danyx.com/colorshift.jpg (permission to use the image to test the color reproduction is of course granted hereby).
Thanks for your help, I hope Adobe will listen soon,
Daniel

H264 HD Color Shift

I've searched the forums and found some references to something similar having to do with h264's encoding for HD and SD differently with rec601 and rec709 (http://forums.adobe.com/thread/769015) but we seem to have the opposite problem where outputting from AE directly works and AME gives us shifted colors.
We are using CS6 production premium with all recent updates on PCs.
We have an animation compressed quicktime as a source file that we are trying to output via AME using H264. If we output it as SD, all colors look fine, if we output the same file to HD we get a pretty big color shift, this is with any of the H264 presets in AME - Vimeo, Broadcast, custom, etc, HD color is shifted, SD is correct - same source file. No color management on files or in AE, all files being viewed on the same computer monitor. If we use AME to compress it with something other than H264 the output is fine at both SD and HD. If we take the same source file and output it from AE directly with the H264 preset both SD and HD colors are correct.
Is there something inherently different in the way that AME and AE are using H264, something obvious that we're missing or is this a bug?
Thanks in advance for any help....

"If we output it as SD, all colors look fine, if we output the same file to HD we get a pretty big color shift, this is with any of the H264 presets in AME"
This means that the source is rec601.
If opened/queued to AME I'm assuming that if the size is bigger than HD that is is guessing that it is rec709. - basically the check is if Height is greater or equal to 720 it is HD. (height >= 720)
In that case AME will assume it is rec709.
It's up to the exporter to select whether to override the SD/HD auto-detect and force it to rec601/rec709.
Check to see if there is that option in the bundled h.264 encoder. The 3rd party product x264pro does have this override.

Color shift between image viewed in ACR and open in PS

Today I updated Photoshop CC and now I have a slight color shift problem between the same image open in ACR and then opened in Photoshop. It appears to be slightly more saturated in ACR.
I have tried the same thing on another computer and it does NOT have the same problem so it must have been something that happened in the update (ACR was one of the items updated). I have also compared the preferences between the two computers and they are identical.
I guess the next thing to do is to deinstall PS and reinstall????
Any advice would be appreciated.

Any difference between ACR and Photoshop is most likely due to a monitor profile problem. They both use the same monitor profile, but there are differences in the actual conversion so a problem can show up differently between them.
Is your monitor calibrated/profiled, and if so how, using what calibrator? Or are you using the Windows default (sRGB), or perhaps you got a bad manufacturer profile through Windows Update? (yes, that happens frequently).
To find out if the monitor profile is indeed the problem, go to Control Panel > Color Management > Devices. Set sRGB IEC61966-2.1 as default profile (if it isn't already), then relaunch Photoshop/Bridge and see if the difference is still there. If your monitor is wide gamut, use Adobe RGB instead.
Note that this doesn't fix the problem as such, but if you don't have a calibrator sRGB will usually be close enough until you decide to get one.
If you do have and use a calibrator, make sure it is set to make v2 profiles, not v4, and matrix rather than LUT profiles.

How to fix color shift when converting ProPhoto rgb to srgb IE61966-2.1

How do I fix the color shift when converting my photos in photoshop to srgb for the web. I work in lightroom color space prophoto rgb and after editing in photoshop I convert it over but I get a shift in the colors. Thanks

are you working in 16-bit (ProPhotoRGB, you probably should be)
exactly how are you doing the Conversion
MAKE SURE YOU ARE NOT CONVERTING ANY ADJUSTMENT LAYERS (flatten or merge them before convert)
AND MAKE SURE YOU ARE VIEWING THE PROBLEM AREA AT 100% ACTUAL PIXELS when you do the convert

Save For Web Color incorrect color shifting

SFW (CS3) isn't functioning correctly, or perhaps I'm missing a pref or configuration.
When I go to SFW, the image in the SFW window no matter what setting or level (even 100%) and resulting file is lighter, as in washed out, from it's PSD parent.
Even viewing the Original from within SFW is not the at the original levels. It's washed out.
As a test, if I do a Save As from the same PSD parent to a JPEG at 12, the file is the same level quality as it's PSD parent as expected/desired.
As such, SFW is unusable for me.
CS3, Mac Pro Quade Core 2x3GHz, OSX 10.5.5

Thanks Ann. Here's what I have:
In Edit > Color Settings:
Working Spaces: RGB sRGB IEC...
Color Mgmt Polices: Convert to Working RGB
Convert to Profile:
Source Space Profile: sRGB IEC..
Conversion Options:
Engine: Adobe ACE
Intent: Perceptual
Use Black Point Compensation (√)
Use Dither (√)
In SFW: Convert to sRGB is selected
I'm looking at a head shot 72 dpi and the woman's face is lighter using these settings from within SFW looking at what SFW calls "Original" versus the real original outside of SFW.
Saving a SFW jpg at 100% yields a lighter image than doing a Save As jpg at 12.
I have both a HP LP3065 30" and Apple 22" Cinema display and the SFW processed file is lighter on both screens. Although the SFW Original is lighter on the HP than when looking at same on the Cinema. But the output is lighter and consistent viewing on both displays. Lighter than should be.
The Cinema is set to Apple's stock "Apple Cinema Display" profile and HP doesn't support us with a Mac calibrator, but I did the best I could with Apple's - in Prefs > Display.
Regardless, it seems that SFW is the problem (in my logical but limited color mgmt knowledge). I can save as a Save As jpg and get the expected color level consistent with the original on both my HP and Cinema. Isn't this the deciding factor? The consistency across both. Wouldn't that point to SFW being the problem, since Save As works correctly?
And Peter, I totally agree with you, we need to search first. I did on "Save For Web Color Shifting" but didn't find it. I found other SFW issues, but somehow not my issue. Still, my apologies.
Thanks to both.

Lightbox Slideshow - Color shift

I recently uploaded high res images to the Lightbox slideshow in Adobe Muse and updated the existing Adobe Muse site (www.marcmontocchio.com). When checking the slideshow I noticed that the coloring had changed versus what I originally uploaded. They are 2000 longside and their color space is sRGB. There is a color shift going on and I'm wondering if it has anything to do with the color space or the way in which the files are compressed. I've attached screenshots. The left is a screenshot of the original and the right is a screenshot of what is uploaded to the Adobe Muse site (www.marcmontocchio.com). If anyone knows why this may be happening or how to fix it I'd greatly appreciate it.

Easiest way to fix it is to optimize your images before inserting them into Muse using Photoshop's 'Save For Web' or optimize in Fireworks.
Another thing to check would be that your image doesn't have any transperancy set for your lightbox. I notice you have a black background for the lightbox. If your image has any transperancy at all it would make your image darker.

Color shift on Export

I am getting a slight color shift when I export or open in Photoshop CS3. It is very similar to the shift that happened with Bridge CS3 beta before they updated it. The shift seems to be a decrease in brightness, color and contrast.
My settings in Lightroom for open in Photoshop are to use TIFF, 16 bit, ProPhotoRGB, no compression. CS3 is set for ProPhotoRGB as working color space.
Any thoughts on this color shift. I can't get a decent print either, might be related. My monitor is calibrated and profiled.
PS, I looked for this in other threads but couldn't find it. Sorry in advance if this is already being discussed.

Sorry mate have no idea with PC's, hope someone will see this.

There is a major color shift in my artwork image from the photoshop jpeg to dreamweaver - it gets 'g

There is a major color shift in my artwork image from the photoshop jpeg to dreamweaver - it gets 'grayed out', loses color contrast. I checked in Bridge and the color settings are synchronized. The image in photoshop is just like what i get from my Nikon D90 camera. The grayed out image has also been noted by two of my professional printer co. which i use but one of my printers - Modern Postcard - the images in photoshop are perfect. I just need to know what causes the color shift and how to control/manage it, thank you, Kathyrn

I have noted color shifts as well and have come to a few observations.
When you are making a .JPG file and you are trying to make a color in that file be the same color as your website's background, you're going to get a lot of failures. Photoshop will add color information in an ICC file in the meta information in the file if you like. That tends to produce actual colors, but they do not fit a web gamut.
The way I generally deal with images that need high quality is that I use the Save for Web and Other Devices exclusively, either ticking on or off the ICC profile for JPEG files and working with what works best. Saving a JPEG with as much information as is possible is usually the best choice but, since JPEG is a "lossy" compression scheme, you are always going to get some issues.
Additionally, the web browser in question will have control over what is displayed as well.
So try playing with the ICC profile in Photoshop's Save for Web And Other Devices and see if you can't get things a little more reliable.

My Photoshop CS5 color shifts where CS3 does not...

I've been having problems with my current version of Photoshop (CS5) and its "save for web and devices" option. All photos saved for web are significantly color-shifted - more contrasty in some cases, but oddly washed out in others. I've tried altering settings in the "saved for web" feature to no avail.
Even stranger, to my mind, the compressed photos only display the shifted colors when sent through email or posted on-line - not when looking at them in photoshop.
By chance, I recently had to "save for web" some photos using my laptop's CS3 - and here's the rub - they were perfect. No color shift whatsoever. What's more, the settings for my CS3 "save for web" are identical to the CS5 settings. I'm completely flummoxed now, and have taken to transferring photo I need saved for web to my laptop and using the CS3, but this still seems like madness to me.
I know this is a long shot, and of course there are too many variables to be accounted for, but has anyone encountered a color-shift problem with CS5 in partcular? One that does not appear in CS3?
Maybe I should completely reinstall my CS5 and see what happens.
sigh.

Compare what you have in edit >> color settings
then also in save for web >> preview
Most major web browsers now recognize color profiles which is good so mac & pc look alike, btu you may be viewing without profiles depending on what else you are using to view your images.

H.264 for HTML5 color shifting in Safari

Hi,
I've got a video that I'm using AME to compress for use as an HTML5 background. The color needs to match exactly so the video can blend into the background. This is proving impossible because the color values are shifting in Safari relative to the other browsers.
I'm pretty sure this is a color management problem, so my question is how can I either make sure there is no color profile in the encoded .mp4 file I get out of AME, or to embed a specific profile - sRGB for the web seems appropriate?
I'll also look and see if there is a way to disable it in Safari.
Kevin N.

No ideas?
Here is an example of the color shifting (only in Safari):
https://www.tdc.org/type-competition/

No compression QT conversion w/Color Shift

Similar Messages

Maybe you are looking for