Post

Replies

Boosts

Views

Activity

Reply to RAW 9: Color Differences between 9 and 8
Beta 7 (26A5421a): identical to the digit on all three files, both X-T5 DNG ladders included — three seeds now with no movement. One correction to my post above: I wrote "versions 6–8 are insensitive to working color space". My logs cover only 8 and 8.dng, which is what the Feedback report claims; versions 6 and 7 were not measured.
Topic: Photos & Camera SubTopic:
Image Processing Q&A
2w
Reply to List of RAW 9 bugs
Update after beta 7 (26A5421a): identical to the digit — Canon 254.9 / 253.8 / 255.0 and X-T5 253.3 / 185.4 / 214.0 through an sRGB or Display P3 working space under version 9, unchanged from beta 5 and 6. Two things measured since that may help narrow it. The filter's own estimates — neutralTemperature / neutralTint, exposure, baselineExposure, shadowBias, boost, highlight recovery, gamut mapping — are identical between versions 8 and 9 on every 8↔9 pair I have (seven pairs, four makers), so whatever moves is in the render rather than in the framing. And decoding through extended linear sRGB and converting to Display P3 once afterwards tracks version 8 within about 1% on six version-9 ladders across four makers, both 9 and 9.dng.
2w
Reply to List of RAW 9 bugs
Following up on the working-colorspace question above. Yes — the CIContext workingColorSpace seem to decide whether this appears. But it is not caller-side colour management: version 8 is insensitive to the same setting, varying by at most 0.1 code value across five managed working color spaces (and 8.dng is byte-identical), while version 9 varies by a factor of 3.2 on the same file in the same process. In sRGB or Display P3 a Canon EOS 5D Mark III renders at 254.9 / 253.8 / 255.0 under version 9 — very nearly pure white — and at 158.6 / 119.4 / 77.8 under version 8. Full measurements, five working color spaces, three files, two seeds, plus a minimal reproduction filed as FB24435750.
3w
Reply to RAW 9: Color Differences between 9 and 8
The variable is the CIContext's workingColorSpace in my own experience. That might be why this reproduces for some people and not others. Same file, same process, mean R/G/B over a 400×400 centre crop, output color space sRGB throughout. Fujifilm X-T5, DSCF0021.RAF: working color space version 8 version 9 linear sRGB 78.7 / 46.7 / 44.9 79.6 / 47.2 / 44.7 sRGB 78.7 / 46.8 / 44.9 253.3 / 185.4 / 214.0 Display P3 78.8 / 46.8 / 44.9 252.1 / 187.6 / 214.9 extended linear sRGB 78.7 / 46.7 / 44.9 79.6 / 47.2 / 44.7 extended linear Display P3 78.7 / 46.7 / 44.9 71.1 / 50.6 / 40.6 Version 8 varies by at most 0.1 code value across every managed working color space. Version 9 varies by a factor of 3.2. On a Canon EOS 5D Mark III the same comparison is starker: version 8 reads 158.6 / 119.4 / 77.8 in every working space, version 9 reads 158.3 / 120.2 / 76.9 in linear sRGB and 254.9 / 253.8 / 255.0 — very nearly pure white — in both sRGB and Display P3. In short: gamma-encoded working space (sRGB, displayP3) → grossly lifted, largely clipped sRGB-primaried linear (linearSRGB, extendedLinearSRGB) → tracks version 8 to about 1% the output color space does not decide it — both output spaces show the same pattern .version9DNG behaves the same way on a DNG of the same scene, while 8.dng is byte-identical across all five managed working spaces versions 6–8 are insensitive to working color space entirely CIImage.colorSpace reports kCGColorSpaceDisplayP3 under every version including 9, so the output is not carrying an unusual tag One thing worth flagging, because "just use a linear space" has a wrong answer in it: extendedLinearDisplayP3 is linear, so it avoids the gross failure, but version 9 still departs from version 8 there by −5.0% / +6.3% / −40.7% (R/G/B) on the Canon rendered to sRGB. Only sRGB-primaried linear spaces track version 8. So version 9 is sensitive to primaries as well as transfer, and version 8 to neither. Nik — if your working space is linear you would not see this at all, which may be why the reports never reproduced for you. Kuro's saturation observation on the X-T5 is consistent with a gamma-encoded working space; the effect is much larger than "more saturated" suggests once you measure it. Reproduced on 26A5406e and 26A5416b, identical to the last printed digit on both, across three files (X-T5 RAF, X-T5 DNG, Canon CR2), two vendors, two CFA geometries, and both the plain and .dng decoder ladders. Filed as FB24435750 with a self-contained minimal reproduction that prints its own control and reports the effective decoder version on every row, plus a CC0 sample file.
Topic: Photos & Camera SubTopic:
Image Processing Q&A
3w
Reply to RAW 9: Color Differences between 9 and 8
Beta 7 (26A5421a): identical to the digit on all three files, both X-T5 DNG ladders included — three seeds now with no movement. One correction to my post above: I wrote "versions 6–8 are insensitive to working color space". My logs cover only 8 and 8.dng, which is what the Feedback report claims; versions 6 and 7 were not measured.
Topic: Photos & Camera SubTopic:
Image Processing Q&A
Replies
Boosts
Views
Activity
2w
Reply to List of RAW 9 bugs
Update after beta 7 (26A5421a): identical to the digit — Canon 254.9 / 253.8 / 255.0 and X-T5 253.3 / 185.4 / 214.0 through an sRGB or Display P3 working space under version 9, unchanged from beta 5 and 6. Two things measured since that may help narrow it. The filter's own estimates — neutralTemperature / neutralTint, exposure, baselineExposure, shadowBias, boost, highlight recovery, gamut mapping — are identical between versions 8 and 9 on every 8↔9 pair I have (seven pairs, four makers), so whatever moves is in the render rather than in the framing. And decoding through extended linear sRGB and converting to Display P3 once afterwards tracks version 8 within about 1% on six version-9 ladders across four makers, both 9 and 9.dng.
Replies
Boosts
Views
Activity
2w
Reply to List of RAW 9 bugs
Following up on the working-colorspace question above. Yes — the CIContext workingColorSpace seem to decide whether this appears. But it is not caller-side colour management: version 8 is insensitive to the same setting, varying by at most 0.1 code value across five managed working color spaces (and 8.dng is byte-identical), while version 9 varies by a factor of 3.2 on the same file in the same process. In sRGB or Display P3 a Canon EOS 5D Mark III renders at 254.9 / 253.8 / 255.0 under version 9 — very nearly pure white — and at 158.6 / 119.4 / 77.8 under version 8. Full measurements, five working color spaces, three files, two seeds, plus a minimal reproduction filed as FB24435750.
Replies
Boosts
Views
Activity
3w
Reply to RAW 9: Color Differences between 9 and 8
The variable is the CIContext's workingColorSpace in my own experience. That might be why this reproduces for some people and not others. Same file, same process, mean R/G/B over a 400×400 centre crop, output color space sRGB throughout. Fujifilm X-T5, DSCF0021.RAF: working color space version 8 version 9 linear sRGB 78.7 / 46.7 / 44.9 79.6 / 47.2 / 44.7 sRGB 78.7 / 46.8 / 44.9 253.3 / 185.4 / 214.0 Display P3 78.8 / 46.8 / 44.9 252.1 / 187.6 / 214.9 extended linear sRGB 78.7 / 46.7 / 44.9 79.6 / 47.2 / 44.7 extended linear Display P3 78.7 / 46.7 / 44.9 71.1 / 50.6 / 40.6 Version 8 varies by at most 0.1 code value across every managed working color space. Version 9 varies by a factor of 3.2. On a Canon EOS 5D Mark III the same comparison is starker: version 8 reads 158.6 / 119.4 / 77.8 in every working space, version 9 reads 158.3 / 120.2 / 76.9 in linear sRGB and 254.9 / 253.8 / 255.0 — very nearly pure white — in both sRGB and Display P3. In short: gamma-encoded working space (sRGB, displayP3) → grossly lifted, largely clipped sRGB-primaried linear (linearSRGB, extendedLinearSRGB) → tracks version 8 to about 1% the output color space does not decide it — both output spaces show the same pattern .version9DNG behaves the same way on a DNG of the same scene, while 8.dng is byte-identical across all five managed working spaces versions 6–8 are insensitive to working color space entirely CIImage.colorSpace reports kCGColorSpaceDisplayP3 under every version including 9, so the output is not carrying an unusual tag One thing worth flagging, because "just use a linear space" has a wrong answer in it: extendedLinearDisplayP3 is linear, so it avoids the gross failure, but version 9 still departs from version 8 there by −5.0% / +6.3% / −40.7% (R/G/B) on the Canon rendered to sRGB. Only sRGB-primaried linear spaces track version 8. So version 9 is sensitive to primaries as well as transfer, and version 8 to neither. Nik — if your working space is linear you would not see this at all, which may be why the reports never reproduced for you. Kuro's saturation observation on the X-T5 is consistent with a gamma-encoded working space; the effect is much larger than "more saturated" suggests once you measure it. Reproduced on 26A5406e and 26A5416b, identical to the last printed digit on both, across three files (X-T5 RAF, X-T5 DNG, Canon CR2), two vendors, two CFA geometries, and both the plain and .dng decoder ladders. Filed as FB24435750 with a self-contained minimal reproduction that prints its own control and reports the effective decoder version on every row, plus a CC0 sample file.
Topic: Photos & Camera SubTopic:
Image Processing Q&A
Replies
Boosts
Views
Activity
3w