Enabling LOG C color space conversion with cLog or sLOG footage.

Hi Gang,
I shoot Sony F3, Canon C100 and Canon 5DMk3 cameras in their respective LOG modes whenever possible. I would like to apply the newly added LOG LUT feature designated for ARRI footage to footage from these cameras. Although LOG C is different than the other LOG modes, it should be a good starting point to color grading.
Unfortunately, I can't seem to get the ARRI Log C toggle option to appear with my footage. Apparently there is a certain Metadata Tag in Alexa footage which must make it possible for the Radio Button to appear. I basically want to trick my FCP-X interface into believing the footage is ARRI Alexa Log-C footage even though it is actually Canon cLog, Sony sLog or Cinestyle. Yes, I know the Alexa Log-C profile is a bit different from the ideal profiles for each of these cameras, but it should be close enough for my needs. I will then fine tune each individual camera's color corrections using the FCP-X color panes. What I want is the Curve effect which is difficult to mimic using the Standard Color Panes. BTW, I've been using a 3rd party effect called Natress Curves for this until now, but would like to start using the built-in LUT feature instead since my company has multiple editbays which lack 3rd party plugins. Also, using the built-in color space conversion looks much simpler than the techniques I've developed for the Natress Plugin.
Can anyone tell me which metadata tag is necessary in order to activate the LOG-C LUT option? Thanks Matt Thomas

Thanks for the reply BenB. I appreciate your willingness to help with this topic, but I'm not sure you understand what I want to do and why.
I want to use the LUT for its Luma curve in actual color corrections in FCP-X. I am not trying to use it for display of dailies or other uses which are common with LUTs.
LOG space color space is similar, but not identical with many cameras.   ARRI LOG-C is also very similar to the color space used in Cineon and DPX film scans which I used to see regularly. The black points may vary, but I can adjust black points in many ways. The general shape of the LUT curve should be very similar to other curves used to correct other LOG spaces. If these curves were dramatically different from eachother, they wouldn't be defined as LOG space. LOG is a mathematical formula for how the bits are arranged and reserved in the file structure which is somewhat similar to how stills photographers manage Zone System exposure indexes There is no magic about the way ARRI defines this. It is a way for ARRI footage to match 35mm scans easily and other cameras using LOG space such as the ones I am using regularly. I would LOVE to have Apple include specific LOG LUT's for each camera which I use, but since they have not done that yet, I would like to experiement with the included one which is designed for ARRI LOG-C.
I am a very experienced professional and understand very well how and why LUT's are being used in many ways across the industry. Yes, I use Resolve for certain tasks and yes, it is the best place to do advanced color work. The new Resolve LOG color correction pane is very useful and superior to all tools I've seen.   But I also use and enjoy the convenience of keeping my material within FCP-X as much as possible. And in many cases, FCP-X color correction tools are adequate for my needs. But when using Cinestyle, cLOG or sLOG footage on my cameras, controlling the rolloff of highlights is very difficult to do with the simple 3-way controls. in FCP-X.
Since FCP-X has no Luma or RGB curves tool built-in, I currently use the Nattress Curves plugin in an Adjustment layer over my timelines to provide a basic film look. The downside to this is that not all my editbays have licenses for the 3rd party plugins, and also there are some odd workflow issues which would be much simpler to manage the way that FCP-X does with Arri LOG-C footage.
My question is how to trick FCP-X into thinking the footage is LOG-C so I can use the newly added checkbox to interpret the footage using the LOG-C LUT in an early stage of color correction while the footage is still managed in Floating Point color space.
The LOG-C profile in the Nattress plugin works as a very good starting point for advanced color correction for footage shot by Sony F3, Canon C and Canon Cinestyle cameras. In fact, it is also a fairly good starting point for GoPro Hero3 ProTune footage as well. I am not attempting ot use the LOG-C LUT solely for color correction. Instead, I want to use it for CineGamma tonal correction which is only possible with a proper luma or RGB Curve.   I will then use the FCP-X color panes to ad specific modifications to each camera's footage to more closely match what I'm looking for. If I'm dealing with a camera with lower dynamic range, I adjust the FCP-X panes to compensate for that particular camera, then Paste these attributes to all the clips from that camera. This often results in a very good match from camera to camera while using the same LUT for the tonal look.   I would like to test this technique using the built-in ARRI LOG-C feature, but unfortunately, cannot until FCP-X allows me to use the LUT on other kinds of footage.
I hope this makes sense.   Keep in mind I am a very experienced and technical user and have a long history in the blogosphere and forums about these kinds of topics. I have very specific reasons for why I want to do this, and until Apple provides other LOG correction tools or a bonafide Curves tool, I am seeking to find a way to use the LOG-C as an alternative solution. BenB, it could be that Apple has closed out the LUT from other types of footage because of comments from their close peers which are not exactly helpful to actual real-world users. There are many more cLOG, sLOG and Cinestyle users using FCP-X than there are ARRI users and it is unfortunately they chose to limit their features to exclude these somewhat arbitrarily. My goal is to find a workaround for this odd decision and would love any tips or suggestions if the answer lies in the footage Metadata.

Similar Messages

Color space conversions to/from XYZ broken?

I have just started writing a plug-in in which I need to convert data from an RGB space to XYZ and back again. For this I am using the sPSColorSpace->Convert16 function.
Unfortunately, it seems that the conversions to and from XYZ are not performed correctly. I do not know exactly what *is* calculated, but XYZ it's not. One of the giveaways is that the result of the conversion depends on the color space of the RGB data, including the gamma. Instead, the XYZ values should be uniquely defined, independent of the source RGB space.
I have since created a work-around, by using the sPSColorSpace->Convert16 function to convert RGB values to Lab, and converting those to XYZ and back again with my own code. In this way, everything works as expected. However, it's unsatisfactory for two reasons: (1) a basic SDK function seems to be broken, and (2) my workaround is very slow, introducing 4(!) redundant nonlinear transforms per pixel.
Does anyone have similar or contrary experiences? And, assuming I haven't messed up, how should one go about notifying Adobe about this? Thanks in advance!
Simon

>XYZ is a device independent color space, not a transformation of RGB (like HSB).
That is exactly what I meant. Sorry for expressing myself poorly.
The test I did was as follows. I applied my filter as a smart filter to an RGB smart object. I then *converted* (not assigned) the RGB object to another color space using a relative colorimetric conversion. Because my filter operates in the XYZ space, the (visual) output should be unaffected by the color space conversion. Unfortunately, the output changed.
When I changed my filter to use Convert16 to convert to Lab (instead of XYZ) and back, and manually performed the Lab<->XYZ conversion, the (visual) output was indeed independent of the source color space.
My conclusion is that XYZ as calculated by the Convert16 function *is* a 'transformation of RGB', but, you are correct, it shouldn't be. The conversion does not properly account for the source RGB space.
Simon

Is color space conversion destructive?

Is a simple color space conversion from RGB to CMYK, and then back to RGB a destructive process – meaning will image data be altered in a way that makes it different that the original image? Like jpg compression? I’ve been working with multi-spectral image data in 4 bands (channels) that is not recognized by PS in it’s original form (R,G,B,NIR), hence the color space swap in order to manipulate. It is a very kludgy way to work with output from some amazing imagery. If the image is trashed by doing this, it becomes another reason for seeking out a better way to edit them. If it does not negatively effect the data I have a bit more time to find a better way. So far, it’s a tough row to hoe.
Thanks! TLL ( long time no post )

The experimental evidence is that the conversion is a lossy process. Take an image & duplicate it. Change one of the images from RGB to CMYK and back.Then change the blend mode to difference and you will see the resulting image is not black, but has low level colored noise - conversion errors.
Paulo

Different results of color space conversion

I am converting a raw image.
1. First in ProPhoto, passing it to PS CS3, accepting ProPhoto (against the working color space), and then I convert it in sRGB in Edit.
2. Next, converting it in ProPhoto, but when CS3 receives it, I ask for immediate conversion in sRGB, the working space.
3. Third, I change the color sapace in ACR to sRGB and pass the image to CS3.
Of course, the ACR adjustment parameters are identical in the three processes.
1 and 3 are almost identical (a difference layer does show differences, but I don't see them on the results without huge boosting, and that shows quite random, noise-like difference).
However, 1 and 2 are *vastly* different. The difference, boosted by 2 EV clearly shows the original texture, which is determined by a pecularity in the blue channel.
What is the explanation for the difference between the two conversion from ProPhoto to sRGB?
The conversion engine is Adobe (the conversion immediately at receiving the image does not ask me for the engine).
http://www.panopeeper.com/Download/ProPhoto_to_sRGB_Discrepancy.tif contains three layers with the three versions.
http://www.panopeeper.com/Download/ProPhoto_to_sRGB_inProPhoto.tif is the unconverted, i.e. ProPhoto version.

> I played around a bit with your samples and I could get close to your "Converted when receiving" version by using the Microsoft ICM engine (other options like Dither and Black point comp didn't produce big differences that I could see). Is it possible that is what you have as the engine in Edit>Color Settings?
As I posted, I am using the Adobe engine.
> I reproduced your exact steps (but in CS4), and there was no difference whatsoever between the three. Pitch black in difference blend mode.
I don't understand how you reproduced these steps. The file I uploaded is already in sRGB.
Anyway, I repeated the entire procedude carefully, the result is the same.
The raw file can be downloaded from http://www.panopeeper.com/Download/CCC_ISO0100_01208.ARW, the adjustment parameters are in http://www.panopeeper.com/Download/CCC_ISO0100_01208.xmp
With these files it is possible to repeate the entire process.
Pls note, that the conversion from raw to TIFF occured in 16bit mode, I converted the demo file to 8bit in order to reduce the size.

Color space conversion due to transparency ...

Hi there!
Let's assume we have a document that contains two RGB images, one of them is set to 70 % transparency. When printing to PDF, the 70 % transparent RGB image is converted to CMYK, the other one retains its RGB color space ...
I seem to understand that this is due to the current transparency color space setting. I could change that to RGB.
But I wonder: Is there no way to keep the color space here, no matter if it is CMYK or RGB the images are coming with?
Thanks,
Klaus

Klaus,
To learn what happens with flattening and color, you should refer to this excellent document, "Transparency in Adobe Applications: A Print Production Guide."
http://www.adobe.com/designcenter/creativesuite/articles/cs3ip_printprodtrans.pdf
Here's are relevant section (page 24):
Printing transparency: step-by-step
When printing a page containing live transparency from InDesign CS3 and the Transparency Blend Space is set to Document CMYK, the following steps will take place (steps 3 and 6 may perform color conversions):
1 Transparency is detected on a spread by the Flattener.
2 The Flattener refers to the Transparency Blend Space setting to determine the appropriate color space in which to blend transparent objects. In this example, Document CMYK was selected. The Document CMYK color space is determined by the active color settings (Edit > Color Settings).
3 Any image that is tagged with a color space that differs from the selected blend space is converted to Document CMYK.
4 The Flattener flattens the transparency.
5 The flattened data is passed to the print engine.
6 The print engine compares the color information in the flattened data with the Printer Profile color space set in the Print dialog box. If the color settings dont match, the print engine converts the colors to the color space indicated by the Printer Profile.
7 The color-managed job is printed.

Script for color space conversion RGB to CMYK - URGENT Help Wanted

Excuse my ignorance with the basic nature of this question, I don't use InDesign, but I do have a pressing problem regarding it.
My book publisher has just emailed to say that my photography book has been set for the printers in InDesign and the photographs have AdobeRGB color space (which was what I was aksed to send.) The printer needs the images to be in CMYK. The publisher said that he was "pretty sure Adobe Acrobat converts the InDesign files to CMYK" and that he has sent the printer RGB images in the past and they "came out OK". He said that if this will not work, he needs to convert all of the images separately to CMYK.
Can you help with the following:
1. Is he right about the above - can Adobe Acrobat convert the files?
2. Can anyone offer me a script that will convert all of the images in InDesign to CMYK? or will he need to change them individually?
Thanks for any suggestions with this urgent request.
Stephen

1. Acrobat can convert.
2. No need for a script, if the printer needs CMYK, you can export a CMYK pdf.
3. To get the highest quality conversions, you might want to do it in Photoshop.
4. If the images are color managed and the printer has a modern work-flow a color managed RGB PDFX-4 pdf is probably the best way to go...
Harbs

Color space conversion problem when importing JPEG's

Hi,
I'm currently playing with the trial version of LR. While importing JPEG's with different color spaces (sRGB and Adobe RGB) to LR I've noticed a strange effect: There is a small but noticable difference in color, depending if the JPEG was previously saved in AdobeRGB, or sRGB. All the images I've tested so far should not contain critical colors that exceed normal sRGB. When opened in CS2 both versions of a JPEG, AdobeRGB and sRGB, typically look perceptually identical, no matter if I leave the sRGB image to sRGB, or convert it to the working space (AdobeRGB). Also my color-managed image viewer behaves as it should. So I don't think it's a matter of the different color spaces.
Looking at the imported images in LR I would say that the AdobeRGB image is correctly converted while the sRGB image suffers from a slight reddish cast, most noticable in skin tones. The effect is not as strong as if I would load the sRGB image into CS2 and skip color conversion to my working space (AdobeRGB).
The sRGB versions of the JPEG's were obtained from the AdobeRGB JPEG's using CS2 for conversion.
Anyone else here experienced a similar problem? Is this a bug in the xRGB-to-ProPhotoRGB conversion of LR, or a feature?
/Steffen

Hi Uli,
thanks for pointing me to your thread. I followed the discussion with great interest. Actually, I think the effect I am describing here is of different nature and a LOT stronger, at least for the type of images I've tested.
I did some more experiments yesterday with interesting results:
1) When I export a processed RAW from LR to JPEG or PSD, no matter what Color Space (I tested AdobeRGB, sRGB and ProphotoRGB), and re-import those JPEG/PSD's to LR, they look absolutely identical to the RAW I started with. Also, at first glance, they look similar when opened in CS2, but only because I tested with color images. I can indeed see small differences when testing with B/W, as you described in your "Color management bug" thread.
2) When I change the color space of an PSD or JPEG inside CS2 (I used the default setting 'relative colorimetric') and save it to JPEG and then import this JPEG to LR, colors are far off. The strength of this mostly reddish color cast depends on the color space of the imported JPEG, strongest for Prophoto, less strong for Adobe and sRGB. Interestingly, when I convert the color space inside CS2 and save the result to PSD, it will display correctly when imported in LR. Another interesting side effect: the thumbnails of LR-exported JPEG's in the "Open" dialogs of CS2 and LR (I guess those are not color-managed) show the typical color-flatness for the Adobe and even more the ProPhoto version. For the CS2-converted JPEG's, all thumbnails look just a colorful as the thumbnail of the sRGB version.
3) Such an image which doesn't display correctly in LR will keep its color cast when exported again to a JPEG (not sure about PSD). So something goes wrong with the color conversion during the import of such CS2-converted images.
My explanation so far is that CS2 uses a slightly different way of coding the colorspace information in the metadata of JPEG's which somehow prevents LR to recognise the color space correctly.
Can you confirm this behaviour?
Steffen

Color Space Issue with Wide-Gamut monitor

Since getting my new (and carefully calibrated) LaCie 324 monitor, I have noticed that RAW (and maybe other) images exported from Lightroom as
sRGB jpegs look washed out and slightly green when viewed outside of Lightroom (IE8, Firefox, ACDSee, windows 7 viewer). It seems not to matter whether the external application horors embedded color space profiles or not, since the unmanaged ones assume sRGB.
When I bring one of these jpegs into PhotoShop it still looks bad, and not what I see in Lightroom. However, if I Assign the Adobe RGB profile to the image, it immediately looks like the Lightroom version. And if I then Convert that image to sRGB and save it, it looks fine everywhere, even on an uncalibrated standard Dell TN LCD display.
Any ideas what I might be seeing here. A friend with the same monitor has the same problem, which is what is leading me to suspect the monitor.
The first image here is converted from Lightroom with sRGB color space. The second was first assigned the Adobe RGB color profile and then converted and saved out again as a jpeg.
Converted Only

I downloaded and ran the program. My version number appears to be 2.1 if I read the numbers right.
I am still at a loss as to why my sRGB jpegs only look right if I assign the wrong profile to them.
Here are the settings in Windows 7 for color management. The highlighted profile is the one just created for my monitor. Display 2 is my main display. Note the "viewing conditions" setting on the advanced tab. Do you think the rendering intent might be at fault here? In Lightroom, should I use Perceptual over Relative or vice versa?

CMYK and Gray Color Space Conversion

Hi All,
I have read the Adobe Photoshop CS3 SDK and found Color Space Suite which will color conversion, but i can't able to find sample code.
Can anyone guide how to convert color? or any sample?
Regards,
Selvakumar

Hi All,
I have read the Adobe Photoshop CS3 SDK and found Color Space Suite which will color conversion, but i can't able to find sample code.
Can anyone guide how to convert color? or any sample?
Regards,
Selvakumar

Color space conversion YUV 4:2:0 - ??? - 4:2:2 - 4:2:0 ?

Hello all,
My "workflow" is:
1. Import H264 L5 @ Main YUV 4:2:0 video from Canon 5Dmk2 (1080p)
2. Finalize the sequence in Premiere (PRO CS4)
3. Export the footage as "Uncompressed Microsoft AVI" V210 at 10bit YUV 4:2:2
4. Feed to x264 H.264 encoder via Avisynt to convert / frameserve at YV12 (YUV 4:2:0) as required by
the H264 (use Avisynth ConvertToYV12) to get the "raw" H.264 L4.1 @ High YUV 4:2:0 video stream
(5. encode aac, mux with subtitles, and h264 video to mp4 container)
Question is:
a) While converting between the color spaces as above, what kind of quality loss I am experiencing?
b) Any thoughts on how to do this smarter, or if I am outright ruining the footage before it gets to its MP4 container?
c) Is there any way to export the video frrom Premiere (PRO CS4) as uncompressed YV12 (YUV 4:2:0)
(and yes; I know I could use bundled MainConcept H.264 codec, but I like the control x264 gives, and _arguably_ it may produce better looking footage at the same framerate / settings)
Looking forward to hearing some expert advice on the matter at hand!

Thanks Jim.
I gave UT a shot. However I had it crashing few times in encoder. Then googled for alternatives and there seems to be a whole bunch of YV12 capable lossless codecs out there: Hyffuyv, Lagarith, MSU, Snow, and FFV1. I tested some of them, and Lagarith seems to do the trick for me (in Lagarith, setting "prevent upsampling" flag maybe worthwile). So I am now to: 4:2:0 - ??? - 4:2:0; that is:
1. Import H264 YUV 4:2:0 video to premiere
2. Work with the video in premiere and export using "Microsoft AVI - Lagarith lossless codec" to YV12 AVI (YUV 4:2:0)
3. Use Avisynth to frame serve AVI to x264 (only line in avisynth script is AviSource ("inputYV12.avi") )
I wonder what color space Premiere works internally to apply all the effects and everything..
Again - Thanks for making me think alternatives here!!
PS. for v210, I do not have card, but I can export in v210 from premiere. Then I can either use VirtualDubs build-in v210 codec (or YUYV had I exported to that) to convert back to something else. There is also a video for windows codec for v210 that I tried (google: drastic v210) you could use.

Is the color space conversion needed for optimal uploads to Blurb using the book module automatic?

Just uploaded my first book to Blurb using the module in LR4. Blurb recommendations are to upload sRGB if using their software, or to convert to their cmyk profile if using Indesign or a pdf workflow ( I think).
So, I hope that the proper conversion is done automatically when uploading using the new book module. I uploaded a mix of edited raw nefs, edited tifs, psd's, jpegs which normally I would convert upon export to srgb to use in the stand alone booksmart app with great success color wise. I'll see my new books in a couple of weeks, but I'd like to rest easy till then.

Yes, the direct export sends sRGB to Blurb.

How to resolve Invalid Color Space error with IE ?

We are in the progress of upgrading to Acrobat 9.3.4. We have approximately 1400 fillable PDF templates in our repository, and are getting an error displaying 10 of these forms after upgrading to Acrobat 9.3.4. The error is:
"There was an error processing a page. Invalid ColorSpace." All the forms were created with Adobe InDesign, then embellished with fillable form fields using Acrobat 7. From reading other posts, this seems to point to a corrupt PDF, but we do not believe this to be the case and we believe this is a bug in Acrobat 9. Here is what we've witnessed to back up this conclusion...
1.) The problem only occurs when displaying the PDF from within an Internet Explorer browser window (both IE6 & IE8). It does not occur if we simply open the PDF from the file system within Acrobat.
2.) The problem is random and not consistent. We usually get the error, but sometimes it opens fine.
3.) When the problem occurs, we're able to view the PDF by right clicking on the PDF and toggling the "Resolution" settings in the Page Display Preferences (either toggle from 96 to custom, or change the custom number). However, this is not an acceptable long-term workaround for our end users.
4.) We've tried recreating the PDF by opening it up in Acrobat 9 and doing a "save as...". The problem still occurs with the resulting PDF (we have not yet tried altering any other Acrobat options).
5.) The problem does not occur when opened in the browser with earlier versions of Acrobat (7.x for example).
Please provide any update you may have on this issue.

If you create a new application and try to create a new JSF page there are you still getting this error?
If you do then I think something in your installation went wrong - the first step would then be to delete the system directory at: C:\Documents and Settings\youruser\Application Data\JDeveloper and restart JDeveloper.

Color management, printing with InDesign CS3

RGB output devices (this includes essentially all inkjet printers from every manufacturer, when driven by the manufacturer print driver). Inkjet printers driven by a PostScript RIP are considered CMYK output devices, and thus this post does not apply to them.
When printing to RGB output devices from InDesign using the same ICC profiles and settings as in Photoshop, you still get crummy results, in terms of color, that differ from both IDCS2 and other Adobe applications including Photoshop CS3.
InDesign CS2 previously did all rasterizing and color space conversion in InDesign prior to submitting the print job to the OS. In CS3 this was changed to submit PostScript + colorspace information, which is then supposed to be normalized by the OS. Except that it doesn't work. Mac OS X drops the color space information.
The work around is to check "Print as Bitmap" in the advanced section of the IDCS3 print dialog. This causes IDCS3 to do the conversion and generate a bitmap prior to submitting to the OS, rather than depending on the OS to do color conversion or rasterizing, which is the default behavior with IDCS2. Thus you can use the same ICC profiles and print driver settings as with all other Adobe applications, if you choose this option.
Chris Murphy
co-author Real World Color Management 2e

Chris,
First, I am surprised that there has been no response to your post since there were more than a few complaints about the problem in this forum when IDCS3 first came out. So thank you for the solution to this vexing problem.
But I find some of the language in your post a bit problematic:
>InDesign CS2 previously did all rasterizing and color space conversion in InDesign prior to submitting the print job to the OS.
and
>... rather than depending on the OS to do color conversion or rasterizing, which is the default behavior with IDCS2.
The second quote seems incorrect on two counts:
1. It contradicts the first quoted statement.
2. In my mac IDCS2 (version 4.0.5 build 688) in the options area of the color management pane of the print dialog, the only available choice for the Color Handling pop up is "Let InDesign Determine Colors".
So the default behavior with IDCS2 seems to be "Let InDesign Determine Colors".
I am not at all taking issue with the main point of your post, which I welcome wholeheartedly. I just find the second quoted phrase from you post confusing. Can you please clarify.
Returning to your main point, are there any downsides of using the Print as Bitmap method?
Thanks,
Al

When to use ProPhoto RGB color space?

I've read articles recommending to use ProPhoto RGB color space because the color gamut is greater. At the same time, I've had to convert some images I created using ProPhoto RGB templates to sRGB so they will display with the right colors in applications that don't support it. I'm wondering (just curious) when it is appropriate to use this color space. Is it only for professional graphic image designers and photographers who send their images to a professional printer?

in addition to what ssprengel said and some of it may be in other words:
There are several standard profiles listed in a separate section in the menus displaying color profiles when you use Assign Profile, Convert to Profile, and when you choose Working Spaces in the Color Settings. These profiles are so called 'well behaved' or 'editing' color spaces. They are device independent and created synthetically for editing purposes - in these color spaces R=G=B is perfectly neutral gray which makes the numbers of color values make sense when editing images referring to the numbers, histograms, curves, etc. ProPhoto RGB is one of these spaces and have the widest gamut, parts of which exceed the visible spectrum. This allows you to have an image with colors that are not limited to the color gamut of eventual destination color spaces like printers and monitors. That's why some people prefer to use Prophoto RGB for images with destination unknown. When you know the destination, in your case an online printing service, get the color profile used by the printing service, install it on your computer, and use convert (Edit menu > Convert to Profile) from ProPhotoRGB to the color profile of the printer. The color management trys to make the conversion to the best possible color match when the destination color space is with a narrower color gamut and you may see color shift of the colors outside the color gamut of the destination. You can also use soft proof (View > Proof Colors with View > Proof Setup set to the destination profile) to edit (optimize) the colors of your document to the destination before the conversion if you can do better than the color management conversion. It is a good idea to make this on a copy of the original image or different layers dedicated to editing colors for a particular destination (color space).
Also have in mind that the conversion can be done on any other computer with Photoshop provided that along with your image they have the source and destination profile. So it can be done by your printer too but without the printers profile on your computer you wont' be able to proof and edit the final appearance.
If you create or edit your artwork or photos with destination unknown in a color space with a comparatively narrower gamut then when in the future you have the opportunity to use a destination with a wider color space you won't be able to take advantage from all possible colors.

Multiprocessing color space render issue

After installing the newest update of After Effects CC 2014 I am having troubles with my renders while using multiprocessing.
The color space I'm working in is a linearized 32bpc sRGB IEC61966-2.1 When I render without multiprocessing turned on, the render turns out fine, but with it turned on the resulting render is way too bright, as though the gamma has been lifted way too high. I would really like to be able to use multi-processing, since it cuts my render times down to a fifth of what they would be otherwise. Any advice would be much appreciated.
Also, just for fun I took my file back into After Effects CC (12.2) and tried rendering it with multiprocessing without changing any settings and the render turned out just fine, making me think that this is specifically a CC 2014 problem.

This is a bug that was introduced in After Effects CC 2014.1 (13.1). My apologies about this.
First things first: to work around this bug you will need to disable multiprocessing in order to get a color-accurate render, via either RAM preview or via the Render Queue. Alternately, you can use multiprocessing but to get expected colors you must disable color management (set the project's working space to None), or if using Rec. 709 or sRGB you can leave the working space enabled and disable only the Linearize Working Space option.
If you choose to leave multiprocessing enabled and disable color management, you can create the same color transform by applying the Color Profile Converter effect. For example, before rendering via the render queue, pre-compose your final comp and apply the effect to the pre-comp.
We will evaluate a fix for this bug for a future update to After Effects CC 2014. An update is scheduled to release soon (this week or next), but a fix for this bug won't be included; this will have to wait for the next update.
Under the hood, here's what happened to cause this bug:
In After Effects CC 2014.1 (13.1), a color transform to Rec. 709 is automatically added to frames delivered via Dynamic Link when color management is enabled in the project. This is a new behavior in this version, which solved a problem with gamma and/or color shifts when sending frames to Premiere Pro or Adobe Media Encoder, which assume that all incoming Dynamic Link frames are Rec. 709.
When multiprocessing is enabled in After Effects, it uses Dynamic Link to communicate with the subprocesses. In this case, After Effects knows what color profile is being used; no additional color correction is necessary.
Combining these two behaviors we get this bug: an unnecessary color transform to Rec. 709 is being applied to frames rendered when multiprocessing is enabled. We failed to take the multiprocessing case into account when we added the new behavior.
If your project's working space is already Rec. 709 or sRGB (which are functionally the same), you wouldn't notice a difference, since the additional color transform results in no change. Using any other profile would cause a color shift. Enabling the Linearize Working Space option with any profile will introduce a gamma shift.
Again, my apologies about this bug.

Enabling LOG C color space conversion with cLog or sLOG footage.

Similar Messages

Maybe you are looking for