Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: wlong on May 21, 2007, 02:18:43 am
-
Forgive me if this has already been discussed here. I'm not a regular visitor.
I'm amazed at the discovery that CS3 allows you to open and manipulate a jpeg file in Camera Raw. This includes Camera Raw producing a XMP file for the jpeg file.
As I hadnt seen this in the "Whats New" section of the photoshop_cs3_help.pdf, I wondered what other goodies were tucked away?
William Long
Longshots Photography www.longshots.com.au
-
Adobe is probably waiting to see the reaction to what I feel could be a major hurt me button here.
Once you open a JPEG in ACR, it's always going to open there. Fine if you want to edit the image, not if you simply want to view or print it. So how you setup your preferences for JPEGs and what you do with them can cause a bit of user confusion since you kind of have to commit to how you want Photoshop or ACR to handle this one file format (and hence, my discomfort with it). Its far more elegantly handled in Lightroom. You have a single user interface for all supported file formats.
Lastly, why just JPEG? And why is the product still called Adobe Camera Raw? Messy.
-
Forgive me if this has already been discussed here. I'm not a regular visitor.
I'm amazed at the discovery that CS3 allows you to open and manipulate a jpeg file in Camera Raw. This includes Camera Raw producing a XMP file for the jpeg file.
As I hadnt seen this in the "Whats New" section of the photoshop_cs3_help.pdf, I wondered what other goodies were tucked away?
William Long
Longshots Photography www.longshots.com.au
[a href=\"index.php?act=findpost&pid=118789\"][{POST_SNAPBACK}][/a]
Most of the edits that you could do with a JPG in ACR you can also do in Photoshop. One edit that would be easier in ACR would be to adjust the white balance. You only have 8 bits with which to work, but the results can be acceptable for many purposes.
Bill
-
Adobe is probably waiting to see the reaction to what I feel could be a major hurt me button here.
Once you open a JPEG in ACR, it's always going to open there. Fine if you want to edit the image, not if you simply want to view or print it. So how you setup your preferences for JPEGs and what you do with them can cause a bit of user confusion since you kind of have to commit to how you want Photoshop or ACR to handle this one file format (and hence, my discomfort with it). Its far more elegantly handled in Lightroom. You have a single user interface for all supported file formats.
Lastly, why just JPEG? And why is the product still called Adobe Camera Raw? Messy.
[a href=\"index.php?act=findpost&pid=118824\"][{POST_SNAPBACK}][/a]
It's no different from how LR treats RAW files, so it's just giving the same capability to those who do not use LR. Or if you want to use Bridge to open files developed with LR maybe to batch process. Makes perfect sense from that point of view.
-
It's no different from how LR treats RAW files, so it's just giving the same capability to those who do not use LR. Or if you want to use Bridge to open files developed with LR maybe to batch process. Makes perfect sense from that point of view.
[a href=\"index.php?act=findpost&pid=118849\"][{POST_SNAPBACK}][/a]
Yes its no different in functionality, big difference in user experience. ACR is a Photoshop plug-in. When you want to deal with say a Raw, it was pretty obvious you had to invoke ACR within Photoshop. Now we have a file format that might open in ACR as a plug-in or might open in Photoshop as most users expect. And its not easy to have it either way on the fly, especially if you've opened and edited the JPEG in ACR.
BTW, Bridge doesn't open anything, its a browser. You get the impression that pointing to a Raw open's it, and it does, but in ACR. You point to a JPEG, well it might open in ACR, might open in Photoshop. Again, messy.
In LR, its a single, seamless UI experience. You deal with all supported files the same way. You can if you wish, have the grid view show you the file extension and even soft that way.
One product should have been IMHO, the JPEG, Tiff, Raw software solution using metadata editing while and the other, the plug-in should have just stuck with handling raw files. Now the waters are real muddy. Again, why does ACR JUST handle JPEGs and not other rendered files? Why is it still called Adobe Camera Raw?
-
Again, why does ACR JUST handle JPEGs and not other rendered files? Why is it still called Adobe Camera Raw?
[a href=\"index.php?act=findpost&pid=118854\"][{POST_SNAPBACK}][/a]
ACR can also open TIFFs as well as JPGs. Andrew is making a big deal about the possible confusion arising out of this new capability of ACR, but thus far only he is voicing these concerns. Time will tell. Personally, I welcome the new functionality.
Bill
-
Yes its no different in functionality, big difference in user experience. ACR is a Photoshop plug-in. When you want to deal with say a Raw, it was pretty obvious you had to invoke ACR within Photoshop. Now we have a file format that might open in ACR as a plug-in or might open in Photoshop as most users expect. And its not easy to have it either way on the fly, especially if you've opened and edited the JPEG in ACR.
So what's the big deal, it's an option, set it as you would like it to behave and carry on.
And Bridge and LR work differently, wow thanks for telling me, I would never have realised.
BTW, Bridge doesn't open anything, its a browser.
Gosh! Really a browser. You're kidding right? Actually you do open things in Bridge, not to mention ACR is actually a part of Bridge. How do you think it renders the RAW files?
In LR, its a single, seamless UI experience. [a href=\"index.php?act=findpost&pid=118854\"][{POST_SNAPBACK}][/a]
You're 'avin' a larf! Seamless LR, yeah right. I wouldn't call anything with the no. of workarounds and annoyances that LR has, seamless. I bought the wretched programme, but I'm waiting for the 1.1 release before I bother using it.
-
ACR can also open TIFFs as well as JPGs.[a href=\"index.php?act=findpost&pid=118859\"][{POST_SNAPBACK}][/a]
It can? How?
-
Gosh! Really a browser. You're kidding right? [a href=\"index.php?act=findpost&pid=118863\"][{POST_SNAPBACK}][/a]
Not at all. That's exactly what Bridge is. Can you open a Tiff INTO Bridge?
ACR is actually a part of Bridge. How do you think it renders the RAW files?
No, it's a Plug-in.
-
It can? How?
[a href=\"index.php?act=findpost&pid=118869\"][{POST_SNAPBACK}][/a]
Very simple. Use File, Open As and click for the drop down box and select Camera Raw. On my setup *.TIFF is the first type of file listed, followed by *.CRW, *.NEF, and others. I now have a TIFF file open in Camera Raw, ready for needed adjustments. If I open in Camera Raw, the next time I open that TIFF file from Photoshop it wants to open in Camera Raw, but if I use save as in Photoshop and save the file, it then opens normally in PS without ACR. A bit weird, but I have not checked out this behavior fully.
Bill
-
Very simple. Use File, Open As and click for the drop down box and select Camera Raw.[a href=\"index.php?act=findpost&pid=118876\"][{POST_SNAPBACK}][/a]
So you can, my god, a third way to do this! Even more confusing. Ops, doesn't work with PSDs! Or for that mater lots of other file formats. Goofy.
Open your Tiff in ACR, mess around with it, open it in Photoshop then close the file but don't save changes. Now open that Tiff again (just File Open) and you're back in ACR for the file. You have to point to that file, select Tiff and open it again to stay out of ACR. Now try doing the same with a JPEG (that is, try to open a Tiff but select JPEG). No go.
So now you can open Tiff's and JPEGs as Camera Raw but not other files. When you do this, you embed preference for that file (unless you're using JPEGs, the general preferences treats them all the same). So the product works differently with JPEGs than Tiffs. Smooth.
Oh, on the Tiff, have it in say ColorMatch RGB or sRGB, open in ACR but have its workflow settings set to a DIFFERENT color space. When it shows up in ACR, do nothing more than click Open Image button. I have my color settings to warn me about profile mismatch. I get this dialog and I'm told my original ColorMatch RGB file is now in ProPhoto RGB. Where was the warning I was going to convert the orignal? Well there is none but it illustrates the potential danger and complexity here. I simply 'opened' or so it seems, a Tiff in ACR, did nothing but really converted my document color space with no warning or an edit. Imagine if I didn't pay attention or have my profile mismatch warnings on and wasn't using the SAME working space in both ACR and PS.
This isn't a hugely messed up complicated way to handle documents? I think so.
-
So you can, my god, a third way to do this! Even more confusing. Ops, doesn't work with PSDs! Or for that mater lots of other file formats. Goofy.
Open your Tiff in ACR, mess around with it, open it in Photoshop then close the file but don't save changes. Now open that Tiff again (just File Open) and you're back in ACR for the file. You have to point to that file, select Tiff and open it again to stay out of ACR. Now try doing the same with a JPEG (that is, try to open a Tiff but select JPEG). No go.
So now you can open Tiff's and JPEGs as Camera Raw but not other files. When you do this, you embed preference for that file (unless you're using JPEGs, the general preferences treats them all the same). So the product works differently with JPEGs than Tiffs. Smooth.
Oh, on the Tiff, have it in say ColorMatch RGB or sRGB, open in ACR but have its workflow settings set to a DIFFERENT color space. When it shows up in ACR, do nothing more than click Open Image button. I have my color settings to warn me about profile mismatch. I get this dialog and I'm told my original ColorMatch RGB file is now in ProPhoto RGB. Where was the warning I was going to convert the orignal? Well there is none but it illustrates the potential danger and complexity here. I simply 'opened' or so it seems, a Tiff in ACR, did nothing but really converted my document color space with no warning or an edit. Imagine if I didn't pay attention or have my profile mismatch warnings on and wasn't using the SAME working space in both ACR and PS.
This isn't a hugely messed up complicated way to handle documents? I think so.
[a href=\"index.php?act=findpost&pid=118878\"][{POST_SNAPBACK}][/a]
I agree the whole process is convoluted and not well thought out or documented. Adobe needs to do some more work, but the ability to open a JPEG whose white balance is incorrect in ACR is an easy way to fix the problem if you don't have Lightroom. Since I shoot almost exclusively in raw, I won't be using the feature often.
Bill
-
I agree the whole process is convoluted and not well thought out or documented. Adobe needs to do some more work, but the ability to open a JPEG whose white balance is incorrect in ACR is an easy way to fix the problem if you don't have Lightroom. Since I shoot almost exclusively in raw, I won't be using the feature often.
Bill
[a href=\"index.php?act=findpost&pid=118885\"][{POST_SNAPBACK}][/a]
Here's more fun with the potential hurt me buttons discussed.
Open a JPEG or even Tiff in ACR, make some gross tone or color alteration and click Done.
Reopen again. You see the ugly color in ACR.
Open the same file in another product, say Preview or Graphic Converter (it can't read the metadata instructions). Looks totally different.
Lightroom isn't immune to this either.
-
Not at all. That's exactly what Bridge is.
Was my obvious sarcasm, a bit too subtle for you? Duh!
No, it's a Plug-in.
So what? It's how Bridge renders its images, it's an integral and essential part of Bridge, always has been.
Here's more fun with the potential hurt me buttons discussed.
Open a JPEG or even Tiff in ACR, make some gross tone or color alteration and click Done.
Reopen again. You see the ugly color in ACR.
Open the same file in another product, say Preview or Graphic Converter (it can't read the metadata instructions). Looks totally different.
Lightroom isn't immune to this either.
[a href=\"index.php?act=findpost&pid=118870\"][{POST_SNAPBACK}][/a]
Well duh! Judging this post and the others, you simply do not grok the paradigm used by LR/ACR/Bridge. And then you have the audacity to moan about the tool working oddly.
Do you also whinge about how you cannot see the hidden layers in PSD files when looking at them in say Word or Safari? Oh, I forgot you cannot even view them at all in those programmes. So PSDs and Photoshop must be bad too, for making files that not every programme can read completely.
As you missed the point above, treating Jpegs in ACR is an option. If it bothers you, do not tick box to open in RAW. Problem solved. That's what I do.
-
So what? It's how Bridge renders its images, it's an integral and essential part of Bridge, always has been.
No, Bridge doesn't render the image, ACR, a plug-in does. Bridge just points to the file and calls up a totally different 'application'.
Well duh! Judging this post and the others, you simply do not grok the paradigm used by LR/ACR/Bridge.
Oh, I get it. If only I could share with you, conversations I and others (guys like Bruce Fraser)made as alpha testers to Adobe about this, when you didn't have a clue CS3 even existed! I'm talking November of 05 buddy.
And then you have the audacity to moan about the tool working oddly.
Yup, and I'm not alone.
Do you also whinge about how you cannot see the hidden layers in PSD files when looking at them in say Word or Safari?
Is whinge a word?
No, I'm not talking about Word or Safari. And I didn't say anything about hidden layers. Open a JPEG in any application other than ACR or LR after making adjustments there and tell me what the preview looks like. They don't match, not even close.
As you missed the point above, treating Jpegs in ACR is an option
No really? Thanks for pointing that out to me. You're a weight of information and a pleasure to communicate with (Was my obvious sarcasm, a bit too subtle for you?)
The point isn't there's an option or that we shouldn’t be able to handle JPEGs like raws with metadata edits. The point is, the current implementation is super sloppy.
We haven't even discussed what a poor engine ACR is for handling this kind of work considering it's doing all processing in a linear gamma very wide gamut space and has to convert all gamma corrected JPEGs and Tiffs to this tone response curve then back to simply apply the edits. A good deal of JPEGs are going to fall apart in a bad way using this process. ACR's engine was designed for linear encoded high bit raw data. If you don't know the vast differences between that and a rendered gamma corrected JPEG, we need to start a new thread and start the education process.
JPEG and rendered metadata editing is useful. Doing it in ACR, even if you fixed this kludge of a workflow and user options is still a very bad idea. Its as Bruce said, a clever hack.
-
... The point is, the current implementation is super sloppy.
We haven't even discussed what a poor engine ACR is for handling this kind of work considering it's doing all processing in a linear gamma very wide gamut space and has to convert all gamma corrected JPEGs and Tiffs to this tone response curve then back to simply apply the edits. A good deal of JPEGs are going to fall apart in a bad way using this process. ACR's engine was designed for linear encoded high bit raw data. ...
I don’t have any particular shares here,
but this sounds like a lack of 16 bit support
for both gamut conversions and the work in-between in said linear-gamma ProPhoto space (?).
Best regards, Peter
--
-
I don’t have any particular shares here,
but this sounds like a lack of 16 bit support
for both gamut conversions and the work in-between in said linear-gamma ProPhoto space (?).
--
[a href=\"index.php?act=findpost&pid=119012\"][{POST_SNAPBACK}][/a]
Having a 16-bit pathway would help. But you've already toss away a huge amount of usable data going to an output referred tone corrected rendering just to go back into a linear space just to apply edits. IOW, ideally, a rendered image in gamma corrected space would be handled one way, raw linear another (and in such a way that the user doesn't have to tell the app which is which and neither pipeline affects or hurts the other). It would be nice if one could do the editing, as we have NOW in the working space of the original document too. Going from sRGB to linear encoded ProPhoto back to sRGB (assuming the user wants that out the back end) on 8-bit JPEG isn't ideal and not how editing in Photoshop handles the identical data.
-
Oh, I get it. If only I could share with you, conversations I and others (guys like Bruce Fraser)made as alpha testers to Adobe about this, when you didn't have a clue CS3 even existed! I'm talking November of 05 buddy.
Yup, and I'm not alone.
[a href=\"index.php?act=findpost&pid=118978\"][{POST_SNAPBACK}][/a]
Some of those conversations would be interesting. Unfortunately, Bruce is no longer with us, but from the Lightroom Podcast No 8, one could sense some disagreements, which were glossed over. Any further comments you can share with us Andrew?
The point isn't there's an option or that we shouldn’t be able to handle JPEGs like raws with metadata edits. The point is, the current implementation is super sloppy.
We haven't even discussed what a poor engine ACR is for handling this kind of work considering it's doing all processing in a linear gamma very wide gamut space and has to convert all gamma corrected JPEGs and Tiffs to this tone response curve then back to simply apply the edits. A good deal of JPEGs are going to fall apart in a bad way using this process. ACR's engine was designed for linear encoded high bit raw data. If you don't know the vast differences between that and a rendered gamma corrected JPEG, we need to start a new thread and start the education process.
JPEG and rendered metadata editing is useful. Doing it in ACR, even if you fixed this kludge of a workflow and user options is still a very bad idea. Its as Bruce said, a clever hack.
[a href=\"index.php?act=findpost&pid=118978\"][{POST_SNAPBACK}][/a]
Yes, but isn't the internal working space of Lightroom also linear with ProPhoto chromaticities, and don't some of these limitations also apply to Lightroom?
-
Some of those conversations would be interesting. Unfortunately, Bruce is no longer with us, but from the Lightroom Podcast No 8, one could sense some disagreements, which were glossed over. Any further comments you can share with us Andrew?
Lets just say he saw the writing on the wall.
Yes, but isn't the internal working space of Lightroom also linear with ProPhoto chromaticities, and don't some of these limitations also apply to Lightroom?
[a href=\"index.php?act=findpost&pid=119039\"][{POST_SNAPBACK}][/a]
Yup they do. The only main difference is the way in which its all presented to the user.
-
Having a 16-bit pathway would help. ... IOW, ideally, a rendered image in gamma corrected space would be handled one way, raw linear another (and in such a way that the user doesn't have to tell the app which is which and neither pipeline affects or hurts the other). ... Going from sRGB to linear encoded ProPhoto back to sRGB (assuming the user wants that out the back end) on 8-bit JPEG isn't ideal and not how editing in Photoshop handles the identical data.
Many thanks for sharing these insights.
Much appreciated.
Best regards, Peter
--
-
The point isn't there's an option or that we shouldn’t be able to handle JPEGs like raws with metadata edits. The point is, the current implementation is super sloppy.
We haven't even discussed what a poor engine ACR is for handling this kind of work considering it's doing all processing in a linear gamma very wide gamut space and has to convert all gamma corrected JPEGs and Tiffs to this tone response curve then back to simply apply the edits. A good deal of JPEGs are going to fall apart in a bad way using this process. ACR's engine was designed for linear encoded high bit raw data. If you don't know the vast differences between that and a rendered gamma corrected JPEG, we need to start a new thread and start the education process.
JPEG and rendered metadata editing is useful. Doing it in ACR, even if you fixed this kludge of a workflow and user options is still a very bad idea. Its as Bruce said, a clever hack.
[a href=\"index.php?act=findpost&pid=118978\"][{POST_SNAPBACK}][/a]
Yes, but isn't the internal working space of Lightroom also linear with ProPhoto chromaticities, and don't some of these limitations also apply to Lightroom?
[a href=\"index.php?act=findpost&pid=119039\"][{POST_SNAPBACK}][/a]
Lets just say he saw the writing on the wall.
Yup they do. The only main difference is the way in which its all presented to the user.
[a href=\"index.php?act=findpost&pid=119042\"][{POST_SNAPBACK}][/a]
In the editing of a JPEG with either Camera Raw or Lightroom, the editing is done in a linear space with the chromaticities of ProPhotoRGB. That means that the 8 bit gamma 2.2 JPEG is converted into this space for editing with either program. Why is the process clumsy and destructive with ACR but not with Lightroom?
-
In the editing of a JPEG with either Camera Raw or Lightroom, the editing is done in a linear space with the chromaticities of ProPhotoRGB. That means that the 8 bit gamma 2.2 JPEG is converted into this space for editing with either program. Why is the process clumsy and destructive with ACR but not with Lightroom?
[a href=\"index.php?act=findpost&pid=119174\"][{POST_SNAPBACK}][/a]
Its clumsy in ACR for the reasons specified above (the UI and user experience).
It's equally destructive in both products with an 8-bit JPEG.
Photoshop should be the metadata rendered toolset OR both ACR and LR should treat rendered images and raw's differently.
Right now, ACR/LR is built best for handling linear encoded high bit raw data.
Right now, Photoshop is best built for handling gamma corrected images both high bit and not.
-
Right now, ACR/LR is built best for handling linear encoded high bit raw data.
Right now, Photoshop is best built for handling gamma corrected images both high bit and not.
[a href=\"index.php?act=findpost&pid=119175\"][{POST_SNAPBACK}][/a]
That makes sense, and the corollary of this is that Lightroom and ACR are not the best tools for working on gamma corrected JPEGs and TIFFs, especially those with a bit depth of 8. However, some operations such as white balance are most easily done in a linear space and use of LR/ACR would make sense in these situations. Would you agree?
-
However, some operations such as white balance are most easily done in a linear space and use of LR/ACR would make sense in these situations. Would you agree?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119187\")
I don't know for a fact that WB on rendered images in LR is fundamentally better/easier than using a gray balance technique in Photoshop. There are two profiles based on different illuminants that allow some interesting tweaking to the WB. I do have to say, in the rare cases I've shot (by mistake) half of my images JPEG and the rest Raw under odd, mixed lighting, I wasn't very happy with what I was able to accomplish in LR to fix the JPEGs. I even have some web galleries where I'm pretty sure, anyone looking closely can see which are which:
[a href=\"http://www.digitaldog.net/Xrite_Party/index.html]http://www.digitaldog.net/Xrite_Party/index.html[/url]
A valuable lesson here. If you hand your camera to someone to use to shoot, be sure they didn't set it to shoot JPEG when its returned, a problem in some of these images.
-
I don't know for a fact that WB on rendered images in LR is fundamentally better/easier than using a gray balance technique in Photoshop. There are two profiles based on different illuminants that allow some interesting tweaking to the WB. I do have to say, in the rare cases I've shot (by mistake) half of my images JPEG and the rest Raw under odd, mixed lighting, I wasn't very happy with what I was able to accomplish in LR to fix the JPEGs. I even have some web galleries where I'm pretty sure, anyone looking closely can see which are which:
http://www.digitaldog.net/Xrite_Party/index.html (http://www.digitaldog.net/Xrite_Party/index.html)
A valuable lesson here. If you hand your camera to someone to use to shoot, be sure they didn't set it to shoot JPEG when its returned, a problem in some of these images.
[a href=\"index.php?act=findpost&pid=119195\"][{POST_SNAPBACK}][/a]
Theoretically, WB in a linear space should be easier, since all that is required is to apply a linear multiplier to the red and blue channels. If you have already applied a gamma correction, the WB correction becomes nonlinear and different multipliers need to be applied to the channels for different points along the TRC, especially so if the TRC involves a contrast adjustment along with the gamma correction. As I understand it, ACR and LR simply undo the gamma correction when the editing is performed and then reapply it for output. As with all data conversions, data may be lost in the process.
In his discussion of the white balance and calibrate adjustments in Adobe Camera Raw, Bruce Fraser states (page 31, Real World Camera Raw with Adobe Photoshop CS2) that it is simply impossible to replicate these adjustments in Photoshop. One has to be careful when using the word impossible, but more difficult might have been a more appropriate choice of words.
The color balance in most of the shots of the Xrite party is two yellow for my taste, but perhaps that was the best that could be done under difficult mixed lighting conditions. A better test of white balance of JPEGs in Lightroom would be when the lighting is from one source but with the wrong color temperature. Still there might be difficulties since you have only 8 bits with to work rather than the 12 bits in most raw files.
Bill
-
Yup, the images are a bit on the warm side on purpose since that kind of feels like what the room was like. But I had a heck of a time correcting out a lot of this on the JPEGs and I think you can see how ruddy they look compared to basically the same moves from raws.
As to Bruce's quote, I would think its accurate indeed. Note that at the time, he was referring strictly to raw, linear encoded data.
-
I don't know for a fact that WB on rendered images in LR is fundamentally better/easier than using a gray balance technique in Photoshop. There are two profiles based on different illuminants that allow some interesting tweaking to the WB. I do have to say, in the rare cases I've shot (by mistake) half of my images JPEG and the rest Raw under odd, mixed lighting, I wasn't very happy with what I was able to accomplish in LR to fix the JPEGs. I even have some web galleries where I'm pretty sure, anyone looking closely can see which are which:
http://www.digitaldog.net/Xrite_Party/index.html (http://www.digitaldog.net/Xrite_Party/index.html)
A valuable lesson here. If you hand your camera to someone to use to shoot, be sure they didn't set it to shoot JPEG when its returned, a problem in some of these images.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119195\")
Hi Andrew,
in my opinion no good WB may be performed in camera space. In Photoshp you are able to avoid color casting, but I think that color apparence is different from what is perceived from human visual system.
In my opinion interpolating or extrapolating using 2 curves at very different color temperatures does not accomplish a great result.
In my opinion the color correction must be done in a color space that simulates cone response in a chromatic adaptation.
Look at a photo of yours balanced with a single click in PhotoResamplig
[a href=\"http://img511.imageshack.us/img511/1337/cfrvc1.jpg]http://img511.imageshack.us/img511/1337/cfrvc1.jpg[/url]
Jacopo
-
As to Bruce's quote, I would think its accurate indeed. Note that at the time, he was referring strictly to raw, linear encoded data.
[a href=\"index.php?act=findpost&pid=119218\"][{POST_SNAPBACK}][/a]
Andrew,
You are not following my argument. When Lightroom or ACR works with a JPEG or TIFF file, it applies an inverse gamma function to convert into a linear space, and the resulting file is then treated in the same way as a raw file. Bruce's statement applies in this context to both to the raw, linear encoded data as well as the file converted into a linear space. White balance can be achieved at this time in a way that is very difficult to to in Photoshop with a gamma encoded file.
Bill
-
Andrew,
You are not following my argument. When Lightroom or ACR works with a JPEG or TIFF file, it applies an inverse gamma function to convert into a linear space, and the resulting file is then treated in the same way as a raw file. Bruce's statement applies in this context to both to the raw, linear encoded data as well as the file converted into a linear space. White balance can be achieved at this time in a way that is very difficult to to in Photoshop with a gamma encoded file.
Bill
[a href=\"index.php?act=findpost&pid=119266\"][{POST_SNAPBACK}][/a]
I'm perfectly aware of this. I'm also perfectly aware of Bruce's reservations about doing it this way as opposed to handling the original gamma correct files as such and NOT converting them to a linear encoded space, a big honking one at that, just to apply metadata edits to files that are not in such a color space.
Yup, one might argue that WB in a linear encoded space is the way to fly. That person argued that WB should be applied to Raw files not rendered images who's WB is already backed into the image.
-
Look at a photo of yours balanced with a single click in PhotoResamplig
http://img511.imageshack.us/img511/1337/cfrvc1.jpg (http://img511.imageshack.us/img511/1337/cfrvc1.jpg)
Jacopo
[a href=\"index.php?act=findpost&pid=119232\"][{POST_SNAPBACK}][/a]
And here it is balanced with a single click in Adobe Camera Raw
[attachment=2542:attachment]
Bill
-
And here it is balanced with a single click in Adobe Camera Raw
[attachment=2542:attachment]
Bill
[a href=\"index.php?act=findpost&pid=119275\"][{POST_SNAPBACK}][/a]
Both work (they both do a decent job or removing the warm cast I actually wanted <g>).
The issue is, many of the JPEG's look downright ugly (not a tech word) compared to the Raws when I try to correct them. And sorry guys but the image you're working on wasn't a JPEG but a Raw originally. I guess it's not as obvious which images in the gallery are JPEGs.
If you like, I can place a JPEG and a DNG from the same location on my iDisk and you can work on them. I found that correcting the severe casts (worse since it's ISO 3200) was far more effective and produced much better appearing images from the raws while the JPEGs simply didn't have the correction latitude and produced ugly images.
And, in camera JPEGs are going to respond better (according to Bruce) in this editing environment than non camera generated JPEGs. But that's another story.
-
Image #15 in the gallery was shot as a JPEG (by mistake). Three people, woman in black and white dress etc.
I had to do some serious desaturation and other tweaks and it still looks butt ugly plus the highlights are gone (highlights I know I could have recovered from raw). Its flat too. This would be the JPEG you'd want to play with. Too me, it stands out as ultra ugly compared to the others, even if you don't accept the warm tones of the shots which I like since it was how I recall the scene.
-
Image #15 in the gallery was shot as a JPEG (by mistake). Three people, woman in black and white dress etc.
I had to do some serious desaturation and other tweaks and it still looks butt ugly plus the highlights are gone (highlights I know I could have recovered from raw). Its flat too. This would be the JPEG you'd want to play with. Too me, it stands out as ultra ugly compared to the others, even if you don't accept the warm tones of the shots which I like since it was how I recall the scene.
[a href=\"index.php?act=findpost&pid=119279\"][{POST_SNAPBACK}][/a]
Andrew,
It would be an interesting exercise in white balance if we had the original JPEG. I was not aware that a JPEG produced in camera was any different from one produced in Photoshop after having rendered the image in ACR. I do know that many P&S cameras roll off the shadows in an attempt to hide high noise.
Bill
-
Andrew,
It would be an interesting exercise in white balance if we had the original JPEG. I was not aware that a JPEG produced in camera was any different from one produced in Photoshop after having rendered the image in ACR. I do know that many P&S cameras roll off the shadows in an attempt to hide high noise.
Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119288\")
Can do, its on my iDisk. And it's pretty darn ugly!
File name is:
PMA2007_07March09-44.JPG
My public iDisk:
thedigitaldog
Name (lower case) public
Password (lower case) public
Public folder Password is "public" (note the first letter is NOT capitalized).
To go there via a web browser, use this URL:
[a href=\"http://idisk.mac.com/thedigitaldog-Public]http://idisk.mac.com/thedigitaldog-Public[/url]
For comparison, the image you two were working on (a DNG) is also in the root folder of my public iDisk. It's called PMA2007_07March09_064.dng
If you want to totally neutralize both, by all means do so. I didn't spend a lot of time on these images but I also got frustrated quickly trying to get the JPEG to look even close to the DNG.
As for camera generated versus non camera generated JPEGs, the differences are a few. For one, there's a specific compression that's not too far over the top and the data has (as yet) undergone no editing other than the Raw to JPEG in camera conversions. There's probably less noise than say a scanned image that's been manipulated and then converted to JPEG.
Bruce had this to say about JPEGs:
A JPEG has already had a third of its luminance data discarded, and
then been tone-mapped into a gamma-encoded space. Note that this
invariably involves more complex mapping than a simple gamma
conversion-in-camea JPEG generally has a pretty steep contrast curve
imposed, and liberties have usually been taken with the endpoints.
-
This is an interesting discussion, but I haven't seen anyone mention what I see as a major advantage of the JPEG in ACR workflow, and that is batch processing. Sure, I can do whatever changes I need to a JPEG in Photoshop with no need for ACR. Yes, the tools in ACR and Lightroom work significantly better with RAW files than they do with JPEGs. But if I have a remote camera shooting JPEGs, and all 1660 exposures are a half stop underexposed, this is going to make it a whole lot easier to correct one of them, then apply that correction to all the others at the same time, and save them out with the correction. (Sure, I can create a Photoshop Action for this, but I like creating Actions for things I do on a regular basis, not for one-offs.) This is the same workflow that I use for RAW files anyway, so it's not a major hassle for me to fix all those durn jpegs. (Yes, this really happened.)
-
Can do, its on my iDisk. And it's pretty darn ugly!
File name is:
PMA2007_07March09-44.JPG
My public iDisk:
thedigitaldog
Name (lower case) public
Password (lower case) public
Public folder Password is "public" (note the first letter is NOT capitalized).
To go there via a web browser, use this URL:
http://idisk.mac.com/thedigitaldog-Public (http://idisk.mac.com/thedigitaldog-Public)
For comparison, the image you two were working on (a DNG) is also in the root folder of my public iDisk. It's called PMA2007_07March09_064.dng
If you want to totally neutralize both, by all means do so. I didn't spend a lot of time on these images but I also got frustrated quickly trying to get the JPEG to look even close to the DNG.
As for camera generated versus non camera generated JPEGs, the differences are a few. For one, there's a specific compression that's not too far over the top and the data has (as yet) undergone no editing other than the Raw to JPEG in camera conversions. There's probably less noise than say a scanned image that's been manipulated and then converted to JPEG.
Bruce had this to say about JPEGs:
A JPEG has already had a third of its luminance data discarded, and
then been tone-mapped into a gamma-encoded space. Note that this
invariably involves more complex mapping than a simple gamma
conversion-in-camea JPEG generally has a pretty steep contrast curve
imposed, and liberties have usually been taken with the endpoints.
[a href=\"index.php?act=findpost&pid=119296\"][{POST_SNAPBACK}][/a]
Andrew,
Thanks for making the original JPEG available and for the quotation from Bruce. I downloaded the JPEG and found that any easy WB correction in ACR is impossible. I think the reason for this difficulty is that the blue channel is clipped in the midtone and shadow areas, and these clipped values are lost and beyond recovery.
This view shows the woodwork (presumably white) in the background. The blue channel has a good bell shaped appearance:
[attachment=2547:attachment]
Here is the histogram from the lady's face with the blue channel clipped:
[attachment=2546:attachment]
I think that Bruce's comments are right on and explain the problem. To illustrate the point, here is a shot that was taken in raw under tungsten illumination, but rendered into 8 bit aRGB with daylight WB and saved as a JPEG. This is an attempt to duplicate an in camera JPEG with daylight WB (as compared with the default TRC of my Nikon D200, the roll off in the shadows is less with ACR defaults than with camera defaults). The blue channel is clipped at the shadow end, even though the image is slightly overexposed as shown by the clipped red channel at the highlight end:
[attachment=2548:attachment]
And here is the same shot rendered into 16 bit aRGB with a linear tone curve and the black point set to zero and saved as PSD (so that it can't be opened in ACR--apparently once a TIFF is opened in ACR, it always opens in ACR even if you want to open it in Photoshop). There is some clipping in the blue channel, but much less than the JPEG. WB correction of the saved TIFF with ACR is relatively successful with ACR, whereas WB correction from the 8 bit JPEG is poor. The clipped blues are lost and this produce a yellow cast in the clipped areas.
[attachment=2549:attachment]
-
I think the reason for this difficulty is that the blue channel is clipped in the midtone and shadow areas, and these clipped values are lost and beyond recovery.
That and the fact that I'm at ISO 3200 all add up to a mess. I'm glad I wasn't alone in finding this a piss poor image to correct. The Raws are a lot easier to deal with thankfully. Also, this was just a bunch of fun snapshots so thankfully, I'm not too upset by the switch mid-shoot to JPEG. But it does make me appreciate Raw!
-
This is my analysis:
the Andrew's photo shows an evident clipping in highlights. The dynamic range is too wide. Is raw shoting the answer? May be yes, may be not. In any case raw may give some more chance.
Is the clipping in all channels?
Look at the following images. Red, green and blue channel.
http://img443.imageshack.us/img443/6417/redchannelzs0.jpg (http://img443.imageshack.us/img443/6417/redchannelzs0.jpg)
http://img476.imageshack.us/img476/1701/greenchanneldp6.jpg (http://img476.imageshack.us/img476/1701/greenchanneldp6.jpg)
http://img476.imageshack.us/img476/3298/bluechannelxl6.jpg (http://img476.imageshack.us/img476/3298/bluechannelxl6.jpg)
The blue channel shows more details on the door, revealing an hidden part of the problem.
The photo is, for my taste, too red, but trying to recover does not yield good results in oversaturated areas.
In this areas colors are "completely false".
Bjanes photo is not color balanced, as he stated. In this case will be better to look at the histograms after WB, as wrog WB produces wrong colors.
I think that lights are far away from tungsten as the correction must be performed far from planckian locus. Anyway the histograms, after the WB.
http://img502.imageshack.us/img502/4364/historl1.jpg (http://img502.imageshack.us/img502/4364/historl1.jpg)
Jacopo
-
This is my analysis:
the Andrew's photo shows an evident clipping in highlights. The dynamic range is too wide. Is raw shoting the answer? May be yes, may be not. In any case raw may give some more chance.
Is the clipping in all channels?
The blue channel shows more details on the door, revealing an hidden part of the problem.
The photo is, for my taste, too red, but trying to recover does not yield good results in oversaturated areas.
In this areas colors are "completely false".
[a href=\"index.php?act=findpost&pid=119467\"][{POST_SNAPBACK}][/a]
The highlight clipping in the highlights around the lights is not significant, since they contain no important image elements and may be allowed to blow out. The problem is that the blue channel is completely lacking in data in the midtones and shadows. It might possible to reconstruct the blue channel via calculations from the red and green channel, but Photoshop can not make something from nothing.
Bjanes photo is not color balanced, as he stated. In this case will be better to look at the histograms after WB, as wrog WB produces wrong colors.
I think that lights are far away from tungsten as the correction must be performed far from planckian locus. Anyway the histograms, after the WB.
[a href=\"index.php?act=findpost&pid=119467\"][{POST_SNAPBACK}][/a]
The photo was not supposed to be white balanced. The whole point of the exercise was to emulate what would happen with an in camera JPEG when exposing a tungsten illuminated scene with daylight white balance. The test with a linear TRC and 16 bit conversion was to track down the source of the data loss in the JPEG.
The illumination is not far from the Planckian locus as shown in this screen capture in ACR. I preset the white balance with a reading from a white card.
[attachment=2553:attachment]
You completed the exercise by showing that a decent white balance was possible from the shot with the wrong color balance.
Bill
-
I'm pretty sure the camera was set for Auto White Balance. Been a long day, a glass of wine and I can't find any EXIF data that tells me that this is indeed the case but that's usually how I have the camera set since I'm always using raw and it doesn't really matter (expect of course in this case where my camera was hijacked and I ended up with a few nasty JPEGs).
Going back to the original point of this set of posts. We have a baked JPEG that's pretty butt ugly for a number of reasons and a DNG shot under similar conditions which seem to be more pliable in being corrected in Lightroom. Remember, the initial point was, trying to adjust a JPEG is a lot harder to do than a Raw (duh) but also, is it 'better' to attempt to fix this kind of file in a raw converter like LR or use Photoshop? This is a severely ugly image but one I suspect isn't that rare. We have two possible tools, Photoshop and LR/ACR, at least in the context of this series of posts. Its possible neither can fix this mess, the image is too far gone? Does anyone have a clear idea which tool would be better at bringing this JPEG back into a somewhat acceptable color apparence? Does the WB tool in LR really help or is it too far gone? Is converting a baked gamma encoded JPEG into a linear color space just so we can use LR's tools the right solution?
I don't expect a single image will answer these questions but they are questions I think need to be asked.
-
The highlight clipping in the highlights around the lights is not significant, since they contain no important image elements and may be allowed to blow out. The problem is that the blue channel is completely lacking in data in the midtones and shadows. It might possible to reconstruct the blue channel via calculations from the red and green channel, but Photoshop can not make something from nothing.
The photo was not supposed to be white balanced. The whole point of the exercise was to emulate what would happen with an in camera JPEG when exposing a tungsten illuminated scene with daylight white balance. The test with a linear TRC and 16 bit conversion was to track down the source of the data loss in the JPEG.
The illumination is not far from the Planckian locus as shown in this screen capture in ACR. I preset the white balance with a reading from a white card.
[attachment=2553:attachment]
You completed the exercise by showing that a decent white balance was possible from the shot with the wrong color balance.
Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119475\")
Ok we have a completely different vision of what is color and what an histogram represents.
Let me try to show my point of view:
This is a better balanced result of Rodney photo.
[a href=\"http://img508.imageshack.us/img508/3801/balanjy0.jpg]http://img508.imageshack.us/img508/3801/balanjy0.jpg[/url]
You can think the result is good,"since they contain no important image elements and may be allowed to blow out". NOT FOR ME.
The resulting histograms:
http://img455.imageshack.us/img455/8541/balanhzq9.jpg (http://img455.imageshack.us/img455/8541/balanhzq9.jpg)
Quite different from the original!
I preset the white balance with a reading from a white card.
so
The illumination is not far from the Planckian locus
That is not true.
Jacopo
-
That is not true.
[a href=\"index.php?act=findpost&pid=119480\"][{POST_SNAPBACK}][/a]
Really? I was under the impression that the color temperature slider adjusted temperature along the Planckian locus and tint at right angles to the locus. What is your line of reasoning?
-
Really? I was under the impression that the color temperature slider adjusted temperature along the Planckian locus and tint at right angles to the locus. What is your line of reasoning?
I don't know if this is the behavior, I believe you.
I prefer to speak about color temperature and correlated color temperature.
If you look at the following PhotoPedia article, you can see the planckian locus.
Your photo has a yellow color cast but a magenta color cast too. So you can see that magentas are far away from planckian locus.
But you said that a WB produced using a gray card is performed along the blackbody curve. I said that this kind of WB is able to perform well also if the illuminant is at a "correlated color temperature".
Jacopo
-
I don't know if this is the behavior, I believe you.
I prefer to speak about color temperature and correlated color temperature.
If you look at the following PhotoPedia article, you can see the planckian locus.
Your photo has a yellow color cast but a magenta color cast too. So you can see that magentas are far away from planckian locus.
But you said that a WB produced using a gray card is performed along the blackbody curve. I said that this kind of WB is able to perform well also if the illuminant is at a "correlated color temperature".
Jacopo
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119514\")
You didn't give a reference to the PhotoPedia article, but this [a href=\"http://en.wikipedia.org/wiki/Color_temperature]Wikipedia[/url] article discusses correlated color temperature. WB using a gray card does not necessarily produce values along the Planckian locus, but since my picture was taken under incandescent illumination, I would expect the WB to lie on this locus. In the ACR screen shot the WB readings are 2000 for temperature (this adjustment works in the blue-yellow axis, presumably moving along the Planckian locus), whereas the tint is -2 (this is in the green-magenta axis, which is at right angles to the Planckian locus and parallel to the lines of correlated color temperature as shown in the Wikipedia article). I would consider a tint of -2 very close to the Planckian locus.
Perhaps you are referring to the picture simulating the daylight exposure of a tungsten illuminated scene.
-
Sorry, I missed the reference http://www.photoresampling.com/photopedia/...lor_Temperature (http://www.photoresampling.com/photopedia/index.php/Color_Temperature_and_Correlated_Color_Temperature)
but since my picture was taken under incandescent illumination, I would expect ...
Perhaps the lights were not exactly "incandescent". (tungsten).
I don't know the scale for the -2 value, but :
as explained in the referenced article, the CCT values ar not on perpendiculars from planckian locus in CIE_xy space
as you can see magentas are not so near to planckian locus
Jacopo
-
Sorry, I missed the reference http://www.photoresampling.com/photopedia/...lor_Temperature (http://www.photoresampling.com/photopedia/index.php/Color_Temperature_and_Correlated_Color_Temperature)
Perhaps the lights were not exactly "incandescent". (tungsten).
I don't know the scale for the -2 value, but :
as explained in the referenced article, the CCT values ar not on perpendiculars from planckian locus in CIE_xy space
as you can see magentas are not so near to planckian locus
Jacopo
[a href=\"index.php?act=findpost&pid=119529\"][{POST_SNAPBACK}][/a]
The CIE XY space is not perceptually uniform, and your article states "correlated color temperature is the color temperature of the point on the blackbody locus that is closest in appearance (chromaticity-wise) to the chromaticity of interest. Technically, this means the point on the blackbody locus nearest the point representing the chromaticity of interest when the blackbody locus is plotted not on the CIE-xy chromaticity diagram but rather on the CIE-uv space chromaticity diagram"
Therefore, for this type of plotting you should be using a perceptually uniform space such as CIE-uv or CIE LAB, not CIE-XY. If you want to find the shortest distance from a point to a line, you drop a perpendicular from the point to the line. With CIE-xy the lines of correlated color temperature are not perpendicular to the Planckian locus, but with a perceptually uniform space, I would think that they should be. If you want to nit pick, you should have your ducks lined up in order.
A tint of -2 in the magenta direction is very close to the Planckian locus. Of course, magenta is not on the Planckian locus, which runs in the yellow-blue direction. Really, what point are you trying to make?
-
Going back to the original point of this set of posts. We have a baked JPEG that's pretty butt ugly for a number of reasons and a DNG shot under similar conditions which seem to be more pliable in being corrected in Lightroom. Remember, the initial point was, trying to adjust a JPEG is a lot harder to do than a Raw (duh) but also, is it 'better' to attempt to fix this kind of file in a raw converter like LR or use Photoshop? This is a severely ugly image but one I suspect isn't that rare. We have two possible tools, Photoshop and LR/ACR, at least in the context of this series of posts. Its possible neither can fix this mess, the image is too far gone? Does anyone have a clear idea which tool would be better at bringing this JPEG back into a somewhat acceptable color apparence? Does the WB tool in LR really help or is it too far gone? Is converting a baked gamma encoded JPEG into a linear color space just so we can use LR's tools the right solution?
I don't expect a single image will answer these questions but they are questions I think need to be asked.
[a href=\"index.php?act=findpost&pid=119477\"][{POST_SNAPBACK}][/a]
Andrew,
I don't think that Photoshop and LR/ACR corrections are mutually exclusive. As this discussion has shown, LR/ACR WB correction can work well when the original color information of the JPEG rendering has not been clipped, distorted, or lost. The in camera JPEG rendering takes considerable liberties with the data as pointed out in the Bruce Fraser quote, and the LR/ACR correction may be inaccurate. One could correct as best as possible in LR/ACR and finish up the correction in PS.
Converting from a narrow gamma encoded space to a wide linear space and then back to the original space does entail loss of data. If you work only in Photoshop, no data are lost from conversions. By way of analogy, considerable data are lost when one converts to LAB for corrections and then back to RGB, especially when working in an 8 bit environment. According to Dan Margulis, the losses are not perceptually evident, but according to my memory, you don't necessarily agree with him.
Bill
-
Really? I was under the impression that the color temperature slider adjusted temperature along the Planckian locus and tint at right angles to the locus. What is your line of reasoning?
[a href=\"index.php?act=findpost&pid=119481\"][{POST_SNAPBACK}][/a]
I doubt it does. Its using some correlated color temperature I'm pretty darn sure. We could ask a true color scientist like Karl Lang about this. I think you're correct about the overall angle in color with respect the locus but does it follow it exactly? I would guess not.
Least we forget, the blackbody is based on a theoretical object that doesn't exist. Hence the reason we should use correlated color temperature since so few (any?) natural objects conform to the behavior of this theoretical object (the blackbody).
-
Andrew,
I don't think that Photoshop and LR/ACR corrections are mutually exclusive. As this discussion has shown, LR/ACR WB correction can work well when the original color information of the JPEG rendering has not been clipped, distorted, or lost. [a href=\"index.php?act=findpost&pid=119542\"][{POST_SNAPBACK}][/a]
Well does the JPEG I provide fall into that camp, that's what the camera gave me as a JPEG so I'm not sure I'm following you.
Its possible this image is as equally hopeless to repair in LR or Photoshop. And its probably impossible to attempt to match the same corrections given the difference in toolset, let alone how the processing is being applied.
If my point was, its easier to fix a raw like this than a JPEG, nearly everyone here would say Duh! So that's not a useful point to make however, to digress, there is always Dan Margulius who on his color theory list feels the opposite and said this:
It does, however, beg the question: if saving time is so important that
quality compromises need to be made, why is the raw format being used at all? With rare image-specific exceptions, essentially anybody who is not a beginner will get better final results by shooting JPEG and correcting in Photoshop than an expert can who shoots raw but is not allowed to do any manipulation outside of the acquisition module. And in less time, too. The idea of a raw module is to *empower* the image-manipulation program, not replace it.
-
I doubt it does. Its using some correlated color temperature I'm pretty darn sure. We could ask a true color scientist like Karl Lang about this. I think you're correct about the overall angle in color with respect the locus but does it follow it exactly? I would guess not.
Least we forget, the blackbody is based on a theoretical object that doesn't exist. Hence the reason we should use correlated color temperature since so few (any?) natural objects conform to the behavior of this theoretical object (the blackbody).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119543\")
I don't know if the ACR temperature slider relates to temperature along the Planckian locus or to CCT, but the fact is that (as you point out in your color management book, p 20) CCT is insufficient to specify the color of an illuminant. For example there are an infinite number of spectra having a CCT of 6500K. In ACR one must use the tint slider in addition to the temperature slider. If the illumination is from a black body radiator, the temperature alone is sufficient; otherwise, one must use the tint along with the temperature.
Incandescent illumination is very close to a black body radiator ([a href=\"http://en.wikipedia.org/wiki/Color_temperature]Wikipedia article[/url]) and I have noted that the the temperature slider will usually achieve WB in ACR when one is working with this type of illumination--only a small amount of tint is needed. This doesn't prove anything, but it suggests to me that the temperature slider is along the Planckian locus.
I do wish that Karl Lange would enter into the discussion.
Bill
-
Incandescent illumination is very close to a black body radiator (Wikipedia article (http://en.wikipedia.org/wiki/Color_temperature)) and I have noted that the the temperature slider will usually achieve WB in ACR when one is working with this type of illumination--only a small amount of tint is needed. This doesn't prove anything, but it suggests to me that the temperature slider is along the Planckian locus.
[a href=\"index.php?act=findpost&pid=119561\"][{POST_SNAPBACK}][/a]
But don't forget to add the the fact that a sensor suffers a LOT from metameric failure...they are designed primarily to provide a spectrally accurate response to "Daylight" and thus have R/G/B filters that do that for continuous light that has some sort of balance in the spectra. There is so little blue light in tungsten that there's no way a sensor will have an accurate response under tungsten-blue cutoff filters are very inefficient and there's very little blue light at 3200K or below.
So, regardless of how this stuff is SUPPOSED to work, all this stuff is really a kludge. It's amazing to me we can anything close to anything to actually work.
-
But don't forget to add the the fact that a sensor suffers a LOT from metameric failure...they are designed primarily to provide a spectrally accurate response to "Daylight" and thus have R/G/B filters that do that for continuous light that has some sort of balance in the spectra. There is so little blue light in tungsten that there's no way a sensor will have an accurate response under tungsten-blue cutoff filters are very inefficient and there's very little blue light at 3200K or below.
So, regardless of how this stuff is SUPPOSED to work, all this stuff is really a kludge. It's amazing to me we can anything close to anything to actually work.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119587\")
The blue output of a 3200K bulb is not that bad as shown in this [a href=\"http://www.gelighting.com/na/business_lighting/education_resources/literature_library/catalogs/downloads/cat_ss_fluorescent_appendix.pdf]SPD 3200K Lamp[/url] graph. The relative energy at 400 nm of the 3200K lamp is half that of daylight. This means that the 8.2 um pixel of a Canon EOS 5D can collect more blue light energy than the 5.5 um Nikon D2X can in full daylight. At base ISO both sensors perform quite well at 3200K, but at high ISO noise becomes a problem with the smaller pixel.
Bill
-
This means that the 8.2 um pixel of a Canon EOS 5D can collect more blue light energy than the 5.5 um Nikon D2X can in full daylight. At base ISO both sensors perform quite well at 3200K, but at high ISO noise becomes a problem with the smaller pixel.
[a href=\"index.php?act=findpost&pid=119601\"][{POST_SNAPBACK}][/a]
Which still ignores the fact that blue separation filters over the site are the least efficient. Take a look at the Wratten filter transmission properties (sorry, I can't find my Kodak Filter Guide at the moment) and I think you'll find that between Red Wratten 29, Green Wratten 61 and a Blue Wratten 47, the blue filter's transmission is way low. Add the filter's low transmission properties to the fact that there is reduced blue light and you'll find there just are not a lot photons hitting a blue sensor when used under tungsten light.
-
I do wish that Karl Lange would enter into the discussion.
Bill
[a href=\"index.php?act=findpost&pid=119561\"][{POST_SNAPBACK}][/a]
He can be reached at info@lumita.com
-
Ah...I finally found it. (the book)
A wratten 29 (red) at its primary wavelengths of between 620-700nn is passing about 90% (90.5% at 700nn) of the red light-meaning about 90% efficient. A green 61 at it's peak transmission of 520nn is about 40% (which is one factor of why there are usually two green collection sites) but the blue 47 at peak of 440nn is 50%. The fact that there are two green sites in a Bayer array and a 90% transission efficiency of the red and you see that if you only have 1/2 of the blue light going through a 50% efficient filter and only one site to collect from, the loss of blue data from a digital capture will result in a metameric failure when comparing a capture done under tungsten and one done at D65.
Which is another reason that white balancing using a two axis slider can be problimatic at best. There just isn't a lot of blue data captured with a digital sensor.
-
Really? I was under the impression that the color temperature slider adjusted temperature along the Planckian locus and tint at right angles to the locus. What is your line of reasoning?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119481\")
I doubt it does. Its using some correlated color temperature I'm pretty darn sure. We could ask a true color scientist like Karl Lang about this. I think you're correct about the overall angle in color with respect the locus but does it follow it exactly? I would guess not.
Least we forget, the blackbody is based on a theoretical object that doesn't exist. Hence the reason we should use correlated color temperature since so few (any?) natural objects conform to the behavior of this theoretical object (the blackbody).
[a href=\"index.php?act=findpost&pid=119543\"][{POST_SNAPBACK}][/a]
Well, we have the answer straight from the horses mouth in a reply to my question posted on the Adobe Camera Raw Forum:
[a href=\"http://www.adobeforums.com/cgi-bin/webx/.3bb6a85c.3bc4009b/0]Link to thread[/url]
Quote for those who don't use the Adobe Forums:
Operation of Temperature and Tint sliders in ACR
Bill Janes - 08:46am May 25, 2007 Pacific
I was under the impression that the temperature slider in ACR adjusted for color temperature along the Planckian locus (blue-yellow) and the tint slider adjusted for situations in which the illumination deviates from that of a black body radiator. Is this correct?
Thomas Knoll - 12:06pm May 25, 07 PST (#1 of 1)
Yes.
-
Well, we have the answer straight from the horses mouth in a reply to my question posted on the Adobe Camera Raw Forum:
Link to thread (http://www.adobeforums.com/cgi-bin/webx/.3bb6a85c.3bc4009b/0)
Quote for those who don't use the Adobe Forums:
Operation of Temperature and Tint sliders in ACR
Bill Janes - 08:46am May 25, 2007 Pacific
I was under the impression that the temperature slider in ACR adjusted for color temperature along the Planckian locus (blue-yellow) and the tint slider adjusted for situations in which the illumination deviates from that of a black body radiator. Is this correct?
Thomas Knoll - 12:06pm May 25, 07 PST (#1 of 1)
Yes.
[a href=\"index.php?act=findpost&pid=119635\"][{POST_SNAPBACK}][/a]
I think the question is partially answered. Yes, it sounds like the sliders adjust for color temp along the locus (blue yellow) but does that mean they do this as exactly defined or using CCT? The direction shouldn’t be questionable, of course it moves on that axis. Is it producing those exact SPD's?
-
Ah...I finally found it. (the book)
A wratten 29 (red) at its primary wavelengths of between 620-700nn is passing about 90% (90.5% at 700nn) of the red light-meaning about 90% efficient. A green 61 at it's peak transmission of 520nn is about 40% (which is one factor of why there are usually two green collection sites) but the blue 47 at peak of 440nn is 50%. The fact that there are two green sites in a Bayer array and a 90% transission efficiency of the red and you see that if you only have 1/2 of the blue light going through a 50% efficient filter and only one site to collect from, the loss of blue data from a digital capture will result in a metameric failure when comparing a capture done under tungsten and one done at D65.
Which is another reason that white balancing using a two axis slider can be problimatic at best. There just isn't a lot of blue data captured with a digital sensor.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119627\")
We do not really need to consider Wratten filters to answer the question, since the answer is in the raw files. In some experiments with my D70 I photographed a MacBeth Color Checker under 40 watt tungsten illumination (2950 K according to ACR) and daylight and examined the raw files (converted with Iris and with the pixel values multiplied by 8 to convert from the raw 0..4095 to the PS 0..32767 "16 bit" format). For convenience, the results are displayed in Photoshop as 8 bit. Since the sensor is linear, the pixel value is proportional to the luminance seen by the sensor elements.
Here are the results for daylight, showing the pixel values and histogram for the white patch:
[attachment=2556:attachment]
Here is the same for tungsten, ~2950K
[attachment=2557:attachment]
To achieve white balance, one multiplies the red and blue pixel values by a scaling factor as shown in this [a href=\"http://www.pochtar.com/NikonWhiteBalanceCoeffs.htm]table[/url].
For 2950 the RGB multipliers are 1.32, 1.0, and 2.9. In terms of f/stops, the red channel is down 0.4 stops and the blue channel 1.54 stops.
For daylight the RGB multipliers are 2.06, 1.0, and 1.6, or expressed in f/stops the red and blue channels are down 1.04 and 0.68 stops respectively. These factors have nothing to do with the fact that the Bayer array has twice as many green sensors as blue and red sensors: the missing colors is each Bayer pixel are filled in by interpolation during the demosaicing process. I don't think the differences have anything to do with metamerism.
The from the above pixel values, the ratio of light falling on the blue sensor in daylight to that with tungsten 2950K (daylight:tungsten) is 1.68 or about 0.75 f/stops. This is about the same change in ratio that takes place when you change the ISO on the camera from 100 to 160, and this does not affect performance that much. At low ISO we get very good results with the digital sensor at 2950K. The blue sensors have plenty of light to work with, and they are less taxed in this situation, than when base ISO is increased from 100 to 200 with daylight illumination.
-
But don't forget to add the the fact that a sensor suffers a LOT from metameric failure...
WAY OFF. Here’s another one from Thomas Knoll: "Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix can be used in software to recover the exact XYZ values.”
Referring to ACR, matrix-to-matrix interpolation tries to compensate for remaining imperfections: “Both color matrices are going to be similar. The closer the camera's filters are to "perfect", the closer to two matrices are going to be” (again by T.K.). In addition, Calibrating ACR can compensate for unit-to-unit deviations, or, for the surprising finding – just as Barry Clive Pearson states – that the zero state of the calibrate tab may have its own hidden agenda away from best fit matrices and colorimetric rendering. Anyway.
IF your thesis would be at faintest true, we should instantly trash any Raw conversion software which does NOT use Lut type input profiles per illuminant – such as Camera Raw and Lightroom.
Too bad. And oh, this subject has less to do with whitebalance in terms of linear scaling per R/G/B channel and resulting CIExy moves such as e.g. along the Plankian locus or isotemperature lines thereof (CT slider) and orthogonal CCT lines (Tint). Works nicely with Raw at even light conditions, but does not work very well with output-referred JPEG’s from in-camera conversion where R/G/B curves might be more successful (see Bruce Fraser’s early articles at CreativePro). And while we are at it, gamma encoding is completely irrelevant here, because the sequence of linear scaling and conversion to different gamma even back to 1.0 is commutative.
Cheers! Peter
--
-
I think the question is partially answered. Yes, it sounds like the sliders adjust for color temp along the locus (blue yellow) but does that mean they do this as exactly defined or using CCT? The direction shouldn’t be questionable, of course it moves on that axis. Is it producing those exact SPD's?
[a href=\"index.php?act=findpost&pid=119636\"][{POST_SNAPBACK}][/a]
Maybe you have some fine points for clarification, but the sliders operate exactly as I postulated to the previous poster in this thread. Mr. Knoll's answer is good enough for me.
-
WAY OFF. Here’s another one from Thomas Knoll: "Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix can be used in software to recover the exact XYZ values.”
--
[a href=\"index.php?act=findpost&pid=119650\"][{POST_SNAPBACK}][/a]
Peter,
Thanks for entering the thread. Yes, I remember that answer by Mr. Knoll, which was in response to a question that I had posted. I had presumed that the digital camera filters would get best results when they matched the response of the human cones, but fortunately this stipulation is not needed and camera makers have some latitude in the filters. Unfortunately, he added that current digital camera filters are not linear and so we don't get perfect matches.
From my work with DCRaw, I saw that the source code contains this note: Thanks to Adobe for providing these excellent CAM -> XYZ matrices! The coefficients in the matrix are listed for various camera models. I presume that when one calibrates ACR with the Fors script or manually by Bruce Fraser's method, one is refining the values of these coefficients which describe the characteristics of the camera filters.
Bill
-
Hello Bill,
Yes, I remember this discussion very well: it was Oct. 2005 when the introduction of Simon Tindemann's script challenged Adobe folks - for good reason as I have to add: http://www.xs4all.nl/%7etindeman/raw/color_reproduction.html (http://www.xs4all.nl/%7etindeman/raw/color_reproduction.html)
With best holiday-greetings from a sunny Greek island,
Peter
--
-
Here's more fun with the potential hurt me buttons discussed.
[a href=\"index.php?act=findpost&pid=118895\"][{POST_SNAPBACK}][/a]
Andrew,
I think you need a trademark on the term.
Edmund
-
The CIE XY space is not perceptually uniform, and your article states "correlated color temperature is the color temperature of the point on the blackbody locus that is closest in appearance (chromaticity-wise) to the chromaticity of interest. Technically, this means the point on the blackbody locus nearest the point representing the chromaticity of interest when the blackbody locus is plotted not on the CIE-xy chromaticity diagram but rather on the CIE-uv space chromaticity diagram"
Therefore, for this type of plotting you should be using a perceptually uniform space such as CIE-uv or CIE LAB, not CIE-XY. If you want to find the shortest distance from a point to a line, you drop a perpendicular from the point to the line. With CIE-xy the lines of correlated color temperature are not perpendicular to the Planckian locus, but with a perceptually uniform space, I would think that they should be. If you want to nit pick, you should have your ducks lined up in order.
A tint of -2 in the magenta direction is very close to the Planckian locus. Of course, magenta is not on the Planckian locus, which runs in the yellow-blue direction. Really, what point are you trying to make?
[a href=\"index.php?act=findpost&pid=119535\"][{POST_SNAPBACK}][/a]
CIE_Lab cannot be used as white reference is required.
The orthogonal lines are computed on CIE-uv space and then converted to CIE-xy space for plotting. That was done to save the same dyagram reference.
I confirm that your photo lights are far from Planckian locus.
I confirm that using a graycard you can correct images illuminated by non-blackbody sources.
Jacopo
-
I confirm that your photo lights are far from Planckian locus.
I confirm that using a graycard you can correct images illuminated by non-blackbody sources.
Jacopo
[a href=\"index.php?act=findpost&pid=119879\"][{POST_SNAPBACK}][/a]
Thus far I have seen nothing from you to prove anything. What evidence do you have that my lamps are far from the Planckian locus?
-
Thus far I have seen nothing from you to prove anything. What evidence do you have that my lamps are far from the Planckian locus?
[a href=\"index.php?act=findpost&pid=119914\"][{POST_SNAPBACK}][/a]
You wrote:
You completed the exercise by showing that a decent white balance was possible from the shot with the wrong color balance.
My correctin was deltauv = -0.02 .... far from Planckian locus.
-
You wrote:
My correctin was deltauv = -0.02 .... far from Planckian locus.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119962\")
Without any description of how you derived that Delta uv value, your assertion about the Planckian locus is meaningless. Furthermore a Delta uv of -0.02 is pretty small. See [a href=\"http://www.kenrockwell.com/tech/dslr-comparison/lcds-2006/index.htm]Rockwell[/url].
Since your posts are undocumented assertions not backed up with any explanation or data, they are not worth any further response.
Bill
-
Without any description of how you derived that Delta uv value, your assertion about the Planckian locus is meaningless. Furthermore a Delta uv of -0.02 is pretty small. See Rockwell (http://www.kenrockwell.com/tech/dslr-comparison/lcds-2006/index.htm).
Since your posts are undocumented assertions not backed up with any explanation or data, they are not worth any further response.
Bill
[a href=\"index.php?act=findpost&pid=119968\"][{POST_SNAPBACK}][/a]
I do not wait for any response from you. I write for the forum users.
Anyone can judges.
Just to clarify for readers: the same deltauv on low color temperature produces more distance from Planckian locus. Rockwell reference mentions high color temperature.
Jacopo
-
The illumination is not far from the Planckian locus as shown in this screen capture in ACR. I preset the white balance with a reading from a white card.
[attachment=2553:attachment]
Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=119475\")
For those who are interested in a scientific analysis of the color quality of various lamps, [a href=\"http://www.slrcamerainfo.com/article.php?filename=Lighting-and-Color-]John Beale[/url] has posted an informative article.
The ACR temperature slider moves along the Planckian locus and the tint slider adjusts for deviations from the Planckian locus along the magenta-green axis. Light sources that closely approximate black body radiators have a small tint correction. If the light source has a discontinuous spectrum, the temperature and tint sliders may not be able to produce accurate color matching, as shown by the Imatest plots.