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.

Similar Messages

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

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.

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

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 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

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.

DVI-HDMI-SDI Conversions and Color Space-what is happening?

Can someone explain signal processing when connecting computer monitors and LCD TVs via different connections and conversions?
- DVI to HDMI
- SDI (BM) to DVI
- SDI (BM) to DVI to HDMI
- SDI to DVI to HDMI
Are there differences in how each conversion processes color space? I am looking to keep it consistent when monitoring out of PPro and AE...latest CC versions...both PC and Mac workstations.
We never create media for typical broadcast or other conventional distribution. All media is custom animation for Special Events...large venue projection. But we do run multiple monitors and LCD for content creation and programming...many times running video thru a DVI Matrix or SDI Matrix for signal distribution. So I want to understand how each configuration effects video.
Does PPro always work in RGB? 0-255...AE as well? Or are there settings that must be set for this?
Thanks if anyone can help educate me!
_phil

That is allot of info there and I will list some to get you started
DVI - RGB
HDMI - RGB, YCBCR, or YUV
SDI - YCBCR
Premiere - No color management ie colorspace control. I believe it just uses the media and current display output color space. You would have to ask someone at Adobe there.
AE - Color management ie colorspace control. You can set what space your coming from and going to.
Do you have any colorimeters to calibrate your display devices? If not I suggest you look at X-Rite since it is cross platform OSX and Windows.
Eric
ADK

IPhoto - is it using two different color spaces?

I know I should have a better handle on this whole question by now, but am still confused by the 1.8 vs. 2.2 Gamma issue.
On the recent advice of an Apple PhotoServices tech, I've just changed my main display's Gamma from the default 1.8 to the darker 2.2 -- hoping to maximize consistency between what I see onscreen and what I'll receive in my printed Calendar order. (Everything else is still based on the default "Cinema HD" profile.)
Using one particular JPEG image as a test, I'm seeing something curious:
In Aperture, the image's thumb and its full-screen version look basically the same. But in iPhoto, that same image looks quite different depending on whether I'm viewing it as a thumb (or as an image placed in a Calendar theme), vs. when I double-click that image and see it in iPhoto's Editor window.
When I see it in iPhoto's editing mode, it suddenly looks noticeably lighter -- as if I'd switched my display back to the old 1.8 Gamma.
Can anyone enlighten me here (pardon the pun)? Why does iPhoto's editor window seem to display an image differently than other programs, or even than elsewhere in iPhoto itself? And why am I only seeing this discrepancy after setting my display to the 2.2 Gamma?
John Bertram
Toronto

Okay --
The plot thickens. I followed your suggestion, Terence, and did some tests. Here are the interesting (if confusing) results:
When I open anything from within the iPhotoLibrary folder using Preview, Preview gives the Color Profile info as follows:
Color Model: RGB
ColorSync Profile: Generic RGB Profile
This seems to apply to anything from within the iPhotoLibrary package, whether we’re talking images from the Originals folder, from the Modified folder, or thumbs from the Data folder. And they all (when viewed in Preview) look the same, and they all look “correct” in terms of general contrast.
BUT...
When I do a Finder “Get Info” on those same files, suddenly there are differences.
1) from the Modified folder:
Most images from the Modified folder now say (in Get Info’s “More Info” pane):
Color space: RGB
Profile name: Adobe RGB (1998)*
* (A few give the Profile name as “sRGB IEC61966-2.1”, and the one that got saved as a .psd file says “Camera Sync Profile”. The strange thing is I can’t seem to find any pattern between the images which were modified using my “external editor” -- Photoshop Elements -- vs. the ones which were edited using only iPhoto’s adjustment tools. The bulk of them all say “Adobe RGB (1998)” as the Profile Name.)
Note that these are the same images which, when opened in Preview, ALL claim the “Generic RGB Profile” -- and all look correct under those circumstances.
2) from the Data folder:
Meantime, ALL the thumbnail images which iPhoto has created for its Data folder, when “Get Info’d” in the Finder, all state their Profile name as “sRGB IEC61966-2.1”.
Open the same thumb image in Preview, and it’s back to “Generic RGB Profile” (as well as back to looking correct and not too dark).
3) from the Originals folder:
Finally, images from iPhoto’s Originals folder give no color profile data whatsoever in the “More info” pane of the Finder’s Get Info window. So is this the same as having the “Generic RGB Profile”?
In any case, here are three different folders (Originals, Modified, and Data), and iPhoto appears to be using a different color profile for the images contained in each one -- and in the case of the Modified folder, several different profiles.
Yet all of these images, when opened in Preview, appear to use the “Generic RGB Profile” -- and all appear as they should in terms of Gamma/contrast on screen -- while when viewed within iPhoto the same image will look quite different depending on whether it’s being seen in iPhoto’s regular window (as a thumb or as part of a Calendar layout, for instance -- all too dark) or in iPhoto’s editing window, in which case it suddenly looks fine.
The other mystery is why this discrepancy between iPhoto’s regular viewer and its editing window wasn’t apparent when my display was set to the default 1.8 Gamma; it’s only become an issue under the new (AppleSupport-recommended) 2.2 setting.
= = = = = == = = = = = = = = = = = = = = = = = = = = = = = =
My brain officially hurts now. (I guess this is just more evidence that Computers and the Internet will all be very nice if they can finally just get them working.)
Any help in interpreting this data will, as always, be much appreciated.
Thanks,
John Bertram
Toronto

Converting to different color space

Dear Color Management Guru's,
I have a question regarding converting digital files between color spaces. Is it correct to convert a file from a large color space like Adobe RGB to a smaller color space such as sRGB, or visa versa?
Thanks in advance,
TC

I recently participated in a webinar and the instructor advised that you should 'never convert from from a large space like Adobe RGB to a smaller space like sRGB.
That's not good advice.
Convert when you need to convert. sRGB for web. CMYK for offset, etc.
Furthermore, the instructor recommends that photographers set their cameras to capture in the sRGB space and then later convert to a larger space if the output device can accommodate it.
Also bad advice.
Capturing in sRGB hamstrings you from the outset. Almost every output device (monitor, inkjet, digital press, offset press) can exceed the color gamut of sRGB in at least one dimension. sRGB is the lowest common denominator of color spaces.
My training as a film photographer makes me think that you would want to capture your files with as much data as possible.
You are correct.
At the very least, capture in Adobe98. But you really should be capturing in RAW. It gives you the most leeway when editing the image.
My thinking is that files that are recorded in Adobe RGB and converted to sRGB do indeed loose date. However, the data that is discarded are colors that do not exist in a sRGB file, may be outside of what is perceptible by the eye, is outside of the ability of the output device to record, or colors that do not naturally exist in the subject to begin with.
Well, kinda...
The changes are definitely NOT "outside of what is perceptible by eye."
When moving from Adobe98 to sRGB, you lose a significant amount of color in the blue/cyan part of the spectrum. Try it. Take an image that's been captured in RAW and processed into Adobe98 (or, just captured straight into Adobe98) and contains a deep blue sky or the kind of turquoise you see in a swimming pool or tropical ocean. Convert that image to sRGB and notice what happens to those blues and turquioses. Yuck. But, it is what it is. If the image is headed for the web, that's what you're dealing with.
One question:
Did you pay money for this webinar? You may want to try and get it back.
Beware of the advice you hear on the internet.

What Rendering intent is used when exporting with a different color space?

Hi,
I would be ever so grateful if any one can tell me what rendering intent is used by LR4 when exporting using a custom colour space as there is not an option as there is with the print module.
Thanks.
Message title was edited by: Brett N

Jeff Schewe wrote:
Bob_Peters wrote:
The rendering intent in the Export dialog is Perceptual.
Actually, an RGB color space to RGB colorspace is always only Relative Colorimetric...and adding Perceptual would only work with certain V4 ICC color spaces (you can find perceptual V4 color spaces for sRGB and ProPhoto I think but I'm not sure they would work in Lightroom anyway).
When using an RGB print output profile you can select either Perceptual or Relative and have the intents actually applied.
True.
The case of interest to me is when I have to print a lot of files using a third-party profile and maintain the original filename so it appears on the back. That is why I made the request more than a year ago.
The problem with the Print module is that it clobbers the filename but does allow 2 choices for the rendering intent. Having to deal with weird filenames creates a mess when matching, say, 50 prints with custom notecards.

Lightroom's 4 color "spaces"

I’m working on designing an advanced photography course. This course makes use of Lightroom and Photoshop in the photographic workflow.
I’m learning and researching myself as I go along, and I feel I have reached a ceiling on what I can work out from the sources at my disposal thus far.
So I am turning here for help.
I am trying to clarify how tones and colours are affected from the actual scene through to the printed page. This might seem like overkill to some. However, there is a lot of misunderstanding and confusion, not to mention heated discussions amongst photographers about these issues. I’m experimenting with metering and colour / tone targets and my calculations are only meaningful if I understand how tones and colours are affected at every stage of the workflow.
Here’s how I understand it:
There are 4 (sort of) Colour “spaces” in Develop where a real-time dynamic preview of an image is rendered
1.       The “viewing space” (ProPhotoRGB Chromaticity co-ordinates, sRGB gamma)
2.       The “computational space” (ProPhotoRGB chromaticity co-ordinates, linear gamma – “MelissaRGB”)
(Martin Evening’s Lightroom 3 book published by Adobe press - Appendix B, section on color space page 628-632)
Below that, things get a little fuzzy. According to Jeff Schewe (Real World Camera RAW for CS5, page 32) there is a sort of
3.            “Native Camera Space” and of course there is the
4.            RAW data in the file on disk.
So to generate the dynamically rendered preview, the image goes through the four “layers” as follows (from bottom to top). This is almost certainly flawed, but one has to start somewhere when trying to work things out :-)
1. The RAW file is read from disk. Colorimetric interpretation is performed using a camera profile (e.g. Adobe Standard for whatever camera it is you are using). This process puts the image data into “Native camera space” (“Plotted” onto CIE XYZ with D50 white point)
2. In “Native camera space, the scene white balance (as selected by user, guessed by Lightroom or reported by camera) as well as additional camera calibration panel matrix tweaks “informs” the colorimetric conversion into Lightroom’s “computational space” e.g. Melissa RGB. The colorimetric definition of camera RGB primaries and white is re-DEFINED. The demosaicing as well as chromatic aberration corrections are performed in “native camera space”
3. Almost all image processing calculations occur computationally in the “MelissaRGB Lightroom computational space”
4. What is displayed on the screen, however, has an sRGB tone curve applied. This represents the “viewing” space. The histogram is generated from this and the RGB colour percentage readouts are generated from this as well. In addition, some slider controls from user input are weighted back through the tone curve into the computational space below.
Could someone from Adobe kindly help me to clarify the steps? Eric are you reading this? :-)
Thanks in advance

Sandy - Thanks for the link. The spreadsheets you posted on your site is quite helpful.
Jao – I think what you said goes to the heart of what I am trying to achieve here: “Photograph a grey target at the exact same exposure with the exact same lighting but with different cameras and you'll end up with different values in the raw files” Which is why I encourage photographers to experiment with their cameras in order to understand exactly how the camera will respond in the heat of a real shoot. Set up a scene; take a picture, open in Lightroom. What is clipped and why? Use a reflective spot meter. Repeat. Use a hand held incident meter. Repeat. How much can you reliably recover? Are you happy with what your meter considers the mid-point (and what you set your exposure for on the camera) or do you need to compensate? Just how much latitude do you have between what your camera histogram shows as a blown out highlight and what Lightroom shows as a blown out highlight. This relates to tone. I could go on with more examples, but by now, I am (hopefully) making more sense.
I’m merely trying to clarify that which is already public in order to form a coherent mental picture. And by mental picture I do not mean an accurate representation of the minutiae and maths involved. Think of a subway map. It represents a bird’s eye view of a transportation system in a logical fashion, yet it bears almost no resemblance to the cartographical reality of the physical topography. I really don’t care where the tunnels go, how they were dug, how they are maintained or where they twist and turn. What I AM looking for is a logical (not physical) map. This map tells me where the different lines begin and end, and where I can change from one line to the other. The most important quality of the map as a whole is that it provides context. You can tell, at a glance, how different lines interact with each other and even how it links to other entities such as bus stations or public landmarks.
As many have rightfully pointed out, I should not have to care about the maths/secret sauce/internal calculations. And I don’t. In addition, I am a very happy Lightroom user and I am very comfortable using it. I know what a user needs to know to get his picture from A to B. There is no shortage of information on how to accomplish that.
It might help if I illustrate what I am trying to do below:
Please excuse the low resolution, the maximum height allowed for upload is 600 pixels. The picture below goes on the bottom left of the "layer" picture above.
Even though there are certainly many mistakes in my diagram, this is a helpful visualisation. I derived this diagram from publicly available information. As the subway map, this is a logical (not physical) representation that provides context in a visual form. With a little help from people like Eric I am sure I can correct and expand it. The net result is an enhanced understanding of Lightroom and ACR and where it fits into the photographic process, both in terms of tone and colour.
I am not posting the entire chart here since I am not even certain that a 4 “layered” representation is an appropriate logical representation. I posted the spine of the chart with the 4 “layers” and one part that elaborates on the colorimetric interpretation between the two bottom layers. Comments and corrections are welcomed. And I am convinced that this can be accomplished without divulging anything confidential.

Different results of color space conversion

Similar Messages

Maybe you are looking for