When setting up my project for 5d3 Raw I choose 32bpc and the working space is set to none. Should I change that to one of the other options?(Adobe RGB, Apple RGB, sRGB etc...) I'm on a Mac using AE CC, rendering out to ProRes 4444 for FCPX. Thanks.
Quote from: ilia on August 17, 2013, 04:32:11 PM
When setting up my project for 5d3 Raw I choose 32bpc and the working space is set to none. Should I change that to one of the other options?(Adobe RGB, Apple RGB, sRGB etc...) I'm on a Mac using AE CC, rendering out to ProRes 4444 for FCPX. Thanks.
No, keep it as none.
i have the same exact work flow, but i use a 5D2.
:)
Are you able to see a difference between 16 and 32?
ilia, if you're going to prores then rec709 work space would do, no point going to wider gamut or specifying 'none', undefined primaries the second option I'd consider more dangerous.
You could choose a wider gamut workspace if you wanted and were doing any substantial color processing in camera raw because you're source is higher bit depth than 8bit, wider gamuts are suitable.
@eyeland, Difference between 32bit and 16bit visually you're not going to tell as you're viewing sRGB / rec709 0.0 - 1.0 anyway, the 32bit benefit is hidden, ie: greater precision, no clamping / clipping to 0.0 - 1.0 display space if you push shadows and highlights (of coarse you need to pull them back in to 0 - 1, but nothing is lost going over or under whilst grading), linear domain operations IF you're scaling, sharpening or blending. More control over shadows and highlights at 32bit with AE.
Isn't rec709 for HDTV? What color space is used if none is chosen?
Quote from: ilia on August 18, 2013, 09:31:01 PM
Isn't rec709 for HDTV? What color space is used if none is chosen?
Yes you are right !
I think "none" is your native color space in your Raw file.
I do the bulk of my WB, Color Correction with raw in Photoshop export as tiff 16bit (bake my Look)
i use the RGB wave monitor to clamp it down close to Rec 709(16-235)
I use as my main computer monitor , 32 inch LCD HDTV Sony Bravia Color Calibrated to Full Range
Rec 709 (0-255). So my color space is all ready in hd Color space.
And as i understand the color space Options ( i'm new at this with AE, I come from Autodesk Smoke)
you have 2 color space option to deal with.
That your input color space (DNG's/TIFF's) aka: working color space
and the output monitoring Color space ( if just using main computer monitor or output Via
Capture Card to Grading monitor). Export Prores4444 32 bit Float.
i have a AJA Kona Lhi in MacPro to Panasonic Plasma THX Calibrated to Full Range RGB (0-255).
I have found if i change color spaces , my working space & monitoring space do not match
but that in my Case only, so i guess it depends on your monitoring Equipment.
:)
Quote from: ilia on August 18, 2013, 09:31:01 PM
Isn't rec709 for HDTV? What color space is used if none is chosen?
rec709 is for YCbCr video formats including Prores and general imaging. If you're encoding to Prores 4:4:4 'YUV' or h264 or mpeg4 then it's rec709 primaries and transfer, color matrix may vary depending on resolution. If you're encoding to some RGB variant then it's rec709 primaries, transfer and probably 601 color matrix. Gamma curve and white points to suit rec709 video space or rec709 sRGB if image's or image sequences.
Work space color space is generally about what width of gamut your source file is opened into.
If you're opening an 8bit h264 video file into AE then rec709 or sRGB in the case of Canon / Nikon's / GH3 (MOV) JFIF video is the 'best' workspace 'gamut' for those files any wider and it'll almost certainly lead to color and gradation issues including banding.
As you're using raw then it has no 'colorspace', it's sensor data, that's how come you can set sRGB or AdobeRGB in camera or 'transform' from camera raw space 'open' 'wild' gamut to an intermediate space like XYZ and then to a device referenced output space and specification like sRGB or rec709 (16-235/240) or JFIF for video
But as said if you are going 'straight' to Prores with little color processing in ACR via AE then there's little point transforming from Canon camera space to anything wider than rec709.
Leaving it 'open' ie: camera space could lead to problems with translation of color gamut later when in FCPx, the whole point of color management and 32bit float processing is to make use of it. :-)
Quote from: reddeercity on August 18, 2013, 10:44:48 PM
Yes you are right !
I think "none" is your native color space in your Raw file.
Camera space, there's no real defined color space in raw. You transform Camera Space -> Intermediate Space -> Device Output Space. There's no doubt some design decisions made at sensor that make the output spaces limited to specific ones like sRGB and AdobeRGB.
QuoteI do the bulk of my WB, Color Correction with raw in Photoshop export as tiff 16bit (bake my Look)
i use the RGB wave monitor to clamp it down close to Rec 709(16-235)
I use as my main computer monitor , 32 inch LCD HDTV Sony Bravia Color Calibrated to Full Range
Rec 709 (0-255). So my color space is all ready in hd Color space.
'Full Range' RGB what's that? 0 - 255 8bit range, it makes no sense, YCbCr is described as being 'full range' at times ie: 0 - 255 or 1 - 254 in the case of xvYCC but that doesn't fit into 8bit RGB 0 - 255, or into 16bit Integer, so 32bit float RGB is required to hold and retain 'invalid' RGB values below 0.0 and greater than 1.0. There's none of those in Canon camera raw as it's not HDR but 'invalid' values can be generated in color manipulation.
QuoteAnd as i understand the color space Options ( i'm new at this with AE, I come from Autodesk Smoke)
you have 2 color space option to deal with.
That your input color space (DNG's/TIFF's) aka: working color space
and the output monitoring Color space ( if just using main computer monitor or output Via
Capture Card to Grading monitor). Export Prores4444 32 bit Float.
i have a AJA Kona Lhi in MacPro to Panasonic Plasma THX Calibrated to Full Range RGB (0-255).
I have found if i change color spaces , my working space & monitoring space do not match
but that in my Case only, so i guess it depends on your monitoring Equipment.
:)
Working space is not 'input' space, you tell your software what the source clips input space is ie: Interpret As, and you may have source files from various cameras, you set an overall working space to suit your output generally for the reasons above and here: http://www.cambridgeincolour.com/tutorials/color-spaces.htm & http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm & http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm, preview in sRGB generally unless you have wider choice of monitoring, using a color calibrated display device and if necessary use a view lut or ICC profile depending on what your color managed software uses under the hood to transform for viewing from wider working space to sRGB monitor space.
That's the whole point of color management in grading / editing / image processing software, to do all the transformations by lut or ICC from input through working and to output space.
Yes every thing you said is True :)
But For most of use , we don't need that level of complexity.
We are not working in P3 color space or Film Scan .
We are in Rec 709,
I Grade in 10 YCbCr 0-255 color Space By the way.
In Adobe After Effect and Final Cut Pro X :D
There's nothing complex about it, the apps color management does it for us and the OP specifically asks what working space?
Setting working space to none is in effect switching color management off for the input source and just taking the camera raw generated RGB values through as is and encode out to rec709, fine. But I'd rather use CM and define the working space.
re full range YCbCr, yes and so do I when my intermediate files are YCbCr and scale at last op to proper rec709 levels at final encode as I'm sure you do. But if grading RGB intermediates I'll set a wider color space as working as many do for raw image development.
If you set none and if the app defaults to rec709 or sRGB as a result and do any color adjustments in ACR the gamut is being restricted to rec709 even though you have the benefit of highr bit depth to support wider gamuts for color adjustments.
But if the OP is going straight to Prores with only the necessary black level, highlights and white balance then setting rec709 working space is enough, so seems little point running unnecesary risks by setting to 'none' and possibly getting color and tonal response mangled camera raw assumed as rec709 or sRGB going on.
Y3llow just to be clear, my T2i raw workflow is ACR (AE) 32bpc, render DN x HD 444 10bit for CC and render in Resolve. Which color space "should" I or would you use?
Thanks,
Derrick
For me if going to resolve to grade it would be rec709 with a 'flat' or log type curve. But really just do your own tests to suit you and the way you work.
y3llow I use DL Watson's Flatz 2.3 preset. I know some like to learn everything they can about everything by reading and testing everything. Not I. I tend to learn from others with more experience. You have added to our workflows which saves time and we can work with a little more confidence.
Thanks!
Derrick
Quote from: y3llow on August 19, 2013, 07:41:15 AM
There's nothing complex about it, the apps color management does it for us and the OP specifically asks what working space?
Setting working space to none is in effect switching color management off for the input source and just taking the camera raw generated RGB values through as is and encode out to rec709, fine. But I'd rather use CM and define the working space.
re full range YCbCr, yes and so do I when my intermediate files are YCbCr and scale at last op to proper rec709 levels at final encode as I'm sure you do. But if grading RGB intermediates I'll set a wider color space as working as many do for raw image development.
If you set none and if the app defaults to rec709 or sRGB as a result and do any color adjustments in ACR the gamut is being restricted to rec709 even though you have the benefit of highr bit depth to support wider gamuts for color adjustments.
But if the OP is going straight to Prores with only the necessary black level, highlights and white balance then setting rec709 working space is enough, so seems little point running unnecesary risks by setting to 'none' and possibly getting color and tonal response mangled camera raw assumed as rec709 or sRGB going on.
I See your Point!
I reason i was doing this is, i was trying out the "panavision genesis tungsten log (adobe)"
Lut/icc profile in A.E. for a documentary i was working on, About a Street Artist.
When raw first came out, i like the look so i kept it and apply it to All my Raw & h264.
the only way i could export what i saw was to use "none"
I guess i'll have to explore the color space option again :)
After choosing rec709, should I also go with linear working space?
It doesn't really matter for exporting to DNxHD but any upsampling, uprezzing, sharpening or blending would technically benefit. raws are linear.
Since my iMac does not support rec709, and is set to sRGB, shouldn't I just go with sRGB as the After Effects working space? This would make sure that the images match. Also, if going with rec709 or sRGB, doesn't this make my Raw 14bit only 8bit, even though I'm rendering out to ProRes 4444 12bit. I guess all I would like to know is what settings to use to get the absolute highest quality out of AE for color grading the ProRes 4444. Thanks in advance.
Hi, sRGB imac will be display characteristics, basically a slightly different gamma curve at the base affecting the shadows area compared to rec709. sRGB and rec709 share same color primaries that define 'width' of gamut in the wider scheme of things.
Working space is to do with exactly that, the space in terms of gamut defined by the choice of color space, to manipulate your color values within, wide enough to generally avoid clipping gamut unnecessarily leading to such things as potential anomalies in final image 'quality.'
A wider gamut working space is more of a possibility when working with source files of greater bit depth than 8bit. But decision whether to bother also depends on final delivery ie: rec709 video.
The principle of color management in the case of apps like AE is that you define or in AE terms 'interpret as' your source files color space ie: rec709 for video, sRGB for images or camera raw spaces, set a working space gamut as wide as or a little wider than input sources or in the case of raw where color space is undefined and at greater than 8bit a choice of work space based on widest gamut output you intend going to, in your case rec709 in DNxHD.
Then depending on the width of the gamut of your work space you preview either as rec709 if viewing through a HDTV for example or sRGB monitors depending on your display device disregarding projectors and AE will do the necessary transform and dither from wider working space gamut and bit depth to display space so you see what you'll get in your 8 or 10bit video encode or close to it depending on a host of other factors concerning playback, codecs and the calibration minefield.
Regarding bit depth rec709 doesn't mean 8bit, the two are not related, yes rec709 defined video can be 8bit or 10 or 16bit in YCbCr.
If you encode raw 14bit into 16bit then you have 16bit levels range, whether that's necessary or depending on the source files bit depth worthwhile considering storage cost is another thing. 14bit raw precision into linear RGB minus noise floor setting black level around 4000 to 5000 and sensor saturation of first channel with the other channels scaled accordingly ie: RGB multipliers to get your WB right, will undoubtedly mean not even 14bits worth of levels. Black level (5000) will be set to 0 in 16bit and sensor saturated channel say approx 13584 for a 550D, scaled to 65535 in 16bit.
8bit from raw is not enough really for intermediate storage ie: DNxHD Prores etc, 10bit log probably would be, 16bit linear or gamma encoded more than enough.
So rendering out ProRes 4444 from the 14bit Raw files will be 12bit and display 8bit sRGB on monitor?
Does Prores support 12bit, sorry I only know of 8 and 10bit. But yes, the higher bit depth intermediate gives you better grading advantages, ie: better gradations but when you either encode to 8bit or playback 10 or 12bit intermediates it gets the levels scaled into the lower bit depth and the result dithered to suit your display, which in most cases is either 6 or 8bit.
So what advantages does rec709 have over sRGB?
Quote from: y3llow on August 24, 2013, 05:34:08 PM
Does Prores support 12bit, sorry I only know of 8 and 10bit.
from Apple white papers:
ProRes 4444:
The Apple
ProRes 4444 codec preserves motion image sequences
originating in either 4:4:4 RGB or 4:4:4 Y'CBCR
color spaces. With a remarkably low data
rate (as compared to uncompressed 4:4:4 HD), Apple
ProRes 4444 supports 12-bit pixel
depth with an optional, mathematically lossless alpha channel for true 4:4:4:4 support.
Apple ProRes 4444 preserves visual quality at the same high level as Apple
ProRes 422
(HQ), but for 4:4:4 image sources, which can carry the highest possible color detail.
Very little. :-)
sRGB is derived from the rec709 specification and is described as 'display referred' that is the output is targeted at sRGB monitors, mobile devices for example. http://en.wikipedia.org/wiki/SRGB (http://en.wikipedia.org/wiki/SRGB)
rec709 is described as 'scene referred' that is it's not targeted at a specific device but for all intents it is really, a HDTV for example. http://en.wikipedia.org/wiki/Rec._709 (http://en.wikipedia.org/wiki/Rec._709)
When we typically work on and view images & graphics it's generally assumed that to view 'correctly' they will be to sRGB. When we encode and view video's even if from sRGB imagery they are 'expected' to be rec709 specification. If we view rec709 video on an sRGB monitor it's expected that the rec709 to sRGB adjustment is done for us.
As an aside, there are other variants that use rec709 primaries which offer wider color gamut such as xvYCC (xvcolor) http://en.wikipedia.org/wiki/XvYCC (http://en.wikipedia.org/wiki/XvYCC) and scRGB https://en.wikipedia.org/wiki/ScRGB (https://en.wikipedia.org/wiki/ScRGB) just for completeness.
Quote from: ilia on August 24, 2013, 07:39:57 PM
from Apple white papers:
ProRes 4444:
The Apple
ProRes 4444 codec preserves motion image sequences
originating in either 4:4:4 RGB or 4:4:4 Y'CBCR
color spaces. With a remarkably low data
rate (as compared to uncompressed 4:4:4 HD), Apple
ProRes 4444 supports 12-bit pixel
depth with an optional, mathematically lossless alpha channel for true 4:4:4:4 support.
Apple ProRes 4444 preserves visual quality at the same high level as Apple
ProRes 422
(HQ), but for 4:4:4 image sources, which can carry the highest possible color detail.
I see, 12bit is for imagery + alpha, 10bit + alpha. But as the raw has no alpha then encoding to 12bit 4:4:4:4 seems a little pointless.
ProRes 4444 is in bit depth 16bit
i have not seen any 12 bit ProRes 4444 files.
Normaly all ProRes4444 is 16bit & ProRes 422HQ is 10Bit
It you Check your ProRes4444 is Resolve or A.E. they are always show 16bit.
And from what i under stand about the DNxHD 444 is 10bit, from Resolve.
:)
I've never seen, heard or read of 16bit Prores, where have you found that?
Quote from: y3llow on August 25, 2013, 01:09:51 AM
I've never seen, heard or read of 16bit Prores, where have you found that?
I have done this though Adobe Media Encoder, in the Advance setting.
here a link that talks about it from Apple Support page
http://support.apple.com/kb/HT5151
I see now, thanks. 16bit profile is ARGB not 4:4:4:4 at all.
We use Rec709 (16-235) as our AE working space, then export to DPX with output space set to working space and Cineon options set to full range. This way we can grade by eye in AE, open the files in Resolve (video levels 64-960) with the AE look maintained, but still have enough latitude to make considerable adjustments in Resolve if needs be (super whites and super blacks present in the raw are maintained in the DPX even though they may be clipped by the AE grade).
I don't know if this is the proper way to work with DPXs or with broadcast levels, but it works for us. And we've also submitted these files to broadcast clients and our stock library with no reported problems (though these were timelapse sequences shot cr2 rather than ML raw).
If it works for you then it is all that matters, although I think you may be stretching you levels back an forth between full and broadcast possibly and that is also inferred by your mention of super blacks and whites, there won't be any in raw as its not HDR and rec709 limited range workspace will restrict the possibility also, full range rec709 workspace would allow supers, going to full range cineon if levels scaling also occurs then you've stretched levels out.
But you say it works for you, so that's good.
If I use the full range space then whites/blacks are clipped in the DPX. If I use 16-235 then super whites are retained, if they were present in the raw file.
And I don't see where we're going back and forward? We go from the sensor space straight to rec709 16-235, and stay there. Setting Cineon to full range means it passes the working space unchanged. So our DPX has rec709 colours and gamma with black at 64 and white at 960.
With default settings ACR puts quite a bit of data in the super black/super white portion of the signal, or if a non extended space is used for output, it clips this data.
And when I say we grade by eye in AE, I really mean in ACR.
Quote from: andyshon on August 25, 2013, 04:16:38 PM
If I use the full range space then whites/blacks are clipped in the DPX.
Yes, agreed because 16-235, 240 chroma is 0-255 RGB, 0-255 YCbCr doesn't fit unless converted to RGB using a slightly different calculation or a format like OpenEXR is used and a 32bit work space chosen so you can have levels below 0.0 and highlights greater than 1.0 but then apps like Resolve can't handle EXR but AE can. DPX is an odd choice though unless the recieving app requires it. For AE 16bit half float EXR is a better choice if your talking about holding onto supers.
QuoteIf I use 16-235 then super whites are retained, if they were present in the raw file.
No they don't because supers don't exist in 16-235 they live in 0-15 & 236 to 255 YCbCr. :-) There are no supers going from raw unless you specifically scale them that way into 0-255 YCbCr and then trying to set black RGB at 16 YCC and white at 235 YCC to 255 RGB then you'll get supers but at that point you've scaled luma and chroma back and forth. :-)
raw camera space to RGB is not HDR and a typical 16bit integer pixel format or 10bit log are more than sufficient to hold more than 9 stops of camera raw? Where as your rec709 limited range by specification is typically 5 stops. So it appears you're restricting your 'latitude' and normalizing it into a limited range work space, then later dropping it into a full range cineon space to offer chance for wiggle room, seems like AEs DPX options are the problem, Resolve takes full range DPX? But AE doesn't offer it in its DPX?
QuoteAnd I don't see where we're going back and forward? We go from the sensor space straight to rec709 16-235, and stay there. Setting Cineon to full range means it passes the working space unchanged. So our DPX has rec709 colours and gamma with black at 64 and white at 960.
Well there in lies the confusion and why I mentioned scaling of levels, you say you put rec709 into full range cineon, ie: 0 - 1023 and I said then IF those levels are scaled from 16-235 ie: 64-960 to full range 0-1023 then thats not best practice but you conclude that your levels don't scale, fair enough I did say IF and possibly. :-)
Oops. big plate of humble pie for me. This is not working how I thought it was, how i was told it would, and I'd not checked it properly divy that I am. Thanks for the warning, very timely as it happens.
I usually use essentially this workflow but exporting to DNxHD, which did seem to work. I could pull real data back into highlits or shadows in Resolve. The DPXs definitly don't work like this though. Is there a way to get a proper broadcast levels signal into a DPX from AE, or am I flogging a dead horse?
Canon raw files can contain upto 11 stops, and with some cross channel highlight reconstruction you may get a little more. In my experience a default conversion via ARC to a standard RGB space will clip some of this. And likewise if you grade for output in ARC you are likely to clip some data. But then I much prefer to do this rather than do a low contrast conversion at this point. This makes sense for us as our stuff often goes straight off for stock from AE.
Quote from: andyshon on August 26, 2013, 12:49:58 PM
Oops. big plate of humble pie for me. This is not working how I thought it was, how i was told it would, and I'd not checked it properly divy that I am. Thanks for the warning, very timely as it happens. I usually use essentially this workflow but exporting to DNxHD, which did seem to work. I could pull real data back into highlits or shadows in Resolve.
Not to stray into the minefield of encoding and decompressing video and 'limited' vs ' full range' handling by applications but if you used a rec709 (16-235) workspace in AE to DNxHD then there'd be no supers. If you used the non limited rec709 space you'd very possibly get a DNxHD encode with full range levels and therefore supers. But you can have a situation where a receiving codec like QT may scale levels say 16 - 235 to 0 - 255 giving you a brighter washed out appearance lifting shadows and pulling down highlights or a codec crushing the dark supers to RGB 0 (black) and compressing the highlight supers to RGB 255 (white) and stretching the levels out in between. Possibly giving the appearance of more latitude to play with.
QuoteThe DPXs definitly don't work like this though. Is there a way to get a proper broadcast levels signal into a DPX from AE, or am I flogging a dead horse?
I'd have thought your rec709 (16-235) work space dictated proper broadcast equivalent levels in DPX output. Are you not seeing that then, the part I questioned previously was outputting limited range into DPX full range, seemed like levels scaling might occur?
However is rec709 (16-235) really what you want to develop your raws into though, yes it's your final output space but you're intermediate is DPX and your outputting through Resolve?
Have you tried a wider working space in AE, exporting as full range DPX and importing into Resolve as full range, monitoring in Resolve via a rec709 display lut / calibrated monitor and encoding to rec709 video formats from there? You'll be monitoring / previewing as rec709 (16-235) so things may appear to be clipping and crushing in preview although your scopes should tell you otherwise as the 32bit work space should ensure no clipping whilst you grade and making your choices on how you compress your DR into rec709 for final encode?
QuoteCanon raw files can contain upto 11 stops, and with some cross channel highlight reconstruction you may get a little more.
Well I was being conservative when I said hold more than 9 'stops', linear encoded 16bit tif output will hold theoretically 16 stops with decent gradation which is what really matters rather than theoretical 'stops', 10bit log I'd assume much the same but it's subjective really, first how many stops are really usable re: noise, shooting ISO will affect that, then with regard to mixing from other channels that's a bit subjective too depending on the scene DR, exposure choices and color of light source(s), which channel clips first and how quickly followed by the increased noise from the multiplied weaker channels to get the white balance 'accurate'.
QuoteIn my experience a default conversion via ARC to a standard RGB space will clip some of this. And likewise if you grade for output in ARC you are likely to clip some data. But then I much prefer to do this rather than do a low contrast conversion at this point. This makes sense for us as our stuff often goes straight off for stock from AE.
There's no such thing as 'standard' RGB space :-) and it can be unbounded creating values massively bigger and smaller values than 0.0 - 1.0 display space without clipping, take ACES for example, but Canon raw is neither HDR or ACES. :-) Going back to the 32bit work space, we preview in display space 0.0 - 1.0 so we see clipping 'by eye', visually because our displays can't handle the values but the scopes will show no clipping, so it can be misleading to think data is getting clipped when in reality you can store a wide dynamic range in an intermediate file format and in a 32bit workspace but have to make choices on what to display in a limited DR output like rec709 (16-235) generally at 8bit on 6 or 8bit monitors with typically poor calibration :-)
Thanks y3llow, I like the way you patiently answer questions. Is this your or one of your raw workflows from AE to Resolve?
"Have you tried a wider working space in AE, exporting as full range DPX and importing into Resolve as full range, monitoring in Resolve via a rec709 display lut / calibrated monitor and encoding to rec709 video formats from there? You'll be monitoring / previewing as rec709 (16-235) so things may appear to be clipping and crushing in preview although your scopes should tell you otherwise as the 32bit work space should ensure no clipping whilst you grade and making your choices on how you compress your DR into rec709 for final encode?"
Derrick
Hi, I'm new to raw video and with compressed video such as h264 out of a Canon for example I'm really happy with the appearance of it using Vision Color or Cinelook non grading picture styles, I like the combination with my old manual lenses and the idea of straight out of the camera, so I do very little grading plus I no time to devote to it.:-)
However I have used AE to Resolve for DPX simply because QT decompression in Resolve constantly crashed with the files I was feeding it so just gave upnon it.
I think though with raw, really want as few steps, as little manual intervention and minimum intermediate storage cost as possible to get what we want from raw to a 'usable' format, so I'd not use AE for the raw to intermediate stage at all.
Instead if going to Resolve due to its 'bad' Canon raw handling currently go from raw to a flat output in a flavor of 10bit 4:4:4 or if really need be 16bit tif (if Resolve can handle it) or 10bit log DPX using a batch script, dcraw and imagemagick. Like via tin2tins eyeframe.
Just using dcraw to get a flat linear RGB output to bake WB but with no camera curve applied. Rather than via ACR flattening to combat the camera curve I assume ACR adds before export, but I doon't know, never use it. :-)