Repository navigation
fix(positive): convert a Positive source's primaries after the density corrections - #1593
Open
thetalkingdrum wants to merge 1 commit into
Open
thetalkingdrum wants to merge 1 commit into
thetalkingdrum wants to merge 1 commit into
Conversation
…y corrections A Positive JPEG or profiled TIFF converted its primaries to Adobe RGB in the decode, before the crosstalk unmix, fade and Remove Stain offset. The conversion mixes about 28% of sRGB green into red, and Fade Restoration then scaled that mix with the cyan dye. On a red-faded slide (Red Survival 0.19) the river went from reddish brown (0.25, 0.22, 0.21) to cyan-grey (0.17, 0.22, 0.20), and red and green lost separation. A source whose gamut fits Adobe RGB now keeps its own primaries through the decode and carries the matrix in the camera-matrix slot (source_cam_xyz), marked by a 4th row (is_source_profile). On the Positive path the engines apply that matrix after the density matrix when one is active: CPU through the new negpy_core.relog_matrix kernel, GPU through post rows in the normalization shader. With no density matrix it applies before the log as before. A wider source (ProPhoto) still converts in the decode, with the gamut pass. Estimate and the Remove Stain white read the source channels. A camera RAW keeps its matrix before the log on every path, so its render and Estimate do not change. Its matrix folds the as-shot white balance on a Linear RAW decode, and moving it after the stain offset gave the white border a magenta cast. The UI reads the same marker, so a Positive JPEG does not show as a camera RAW. Bumps THUMBNAIL_RENDER_VERSION to 31 and BOUNDS_VERSION to 3.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#1582 fixed a missing primaries conversion: a Positive sRGB JPEG decoded straight into the Adobe RGB working space, so its greens came out too saturated and colors with green in them shifted hue. The fix converts the primaries in the decode. That is correct on its own, but it puts the conversion before the crosstalk unmix, Fade Restoration and Remove Stain. The sRGB to Adobe RGB matrix mixes about 28% of green into red. Fade Restoration then scales that mix together with the faded cyan dye, so red and green lose their separation. The effect is rare and shows mostly on heavily red-faded JPEGs and TIFFs tagged sRGB: on this slide (Red Survival 0.20), a reddish-brown river turns cyan-grey.
Same Fade Restoration and Remove Stain settings in both (Red 0.20, Green 5.0, Blue 3.72).
Now a source whose gamut fits Adobe RGB keeps its own primaries through the decode. On the Positive path, both engines apply its matrix after the density stage, in linear light: the CPU through a new
relog_matrixkernel, the GPU through extra rows in the normalization shader. A wider source such as ProPhoto still converts in the decode. With no fade, crosstalk or stain offset the render is as before. File loads are about 1.3 s faster at 24 MP, and a CPU preview is about 10 ms slower; the GPU is unchanged. Bumps THUMBNAIL_RENDER_VERSION to 31 and BOUNDS_VERSION to 3.Camera RAWs have the same order on the Transfer and Positive paths: the camera matrix applies before the density stage. This PR does not change them, and they render bit-identical to main. Moving them too needs the white balance split out of the camera matrix and testing on narrowband captures, so it is left for a follow-up. One small related change: with an Input ICC set, a Positive JPEG's embedded primaries are now dropped instead of converted twice. A ProPhoto source still converts twice.