Skip to content

BUGFIX: display and view not in colorspace_data, falls back on colorspace#1910

Open
splidje wants to merge 2 commits into
ynput:developfrom
splidje:bugfix/thumbnail_target_colorspace
Open

BUGFIX: display and view not in colorspace_data, falls back on colorspace#1910
splidje wants to merge 2 commits into
ynput:developfrom
splidje:bugfix/thumbnail_target_colorspace

Conversation

@splidje

@splidje splidje commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

Changelog Description

when display and view not in colorspace_data, falls back on colorspace for target colorspace. Also added plate product base type to families.

…olorspace for target colorspace. Also added plate product base type to families.
@ynbot ynbot added type: bug Something isn't working size/XS labels Jun 29, 2026
@BigRoy

BigRoy commented Jun 30, 2026

Copy link
Copy Markdown
Member

This makes little sense actually, the representation colorspace should represent the colorspace of the representation as it currently stands. As such, it's not the target colorspace, but the source one? Right?

If source == target, there's nothing to color convert?

@BigRoy BigRoy requested a review from jakubjezek001 June 30, 2026 14:02
@BigRoy BigRoy added the community Issues and PRs coming from the community members label Jun 30, 2026
@BigRoy BigRoy requested a review from iLLiCiTiT June 30, 2026 14:02
@splidje

splidje commented Jul 1, 2026

Copy link
Copy Markdown
Contributor Author

The reason I need this fix is that since updating core my thumbnails were coming out double LUT-ed.

Looking at the code I interpreted that colour space dictionary as either having display view or colour space. The logic in the former case appears to use display view as both source and target - which I also found to be a little pointless - so all I've done is filled the gap to have the same logic in the latter case.

And it fixed my thumbnails.

@BigRoy

BigRoy commented Jul 1, 2026

Copy link
Copy Markdown
Member

I see. Yes, that's odd.

I'd rather figure out why this fix fixes things for you. Since colorspace converting to itself should do no conversion whatsoever? As such, which other plug-in is 'misconfiguring' things then? 🤔 Perhaps you can try storing the input image and output image of this plug-in. Is it 1:1 the same? or does it differ? or why does it differ if it has same colorspace, etc.?

@moonyuet

moonyuet commented Jul 7, 2026

Copy link
Copy Markdown
Member

I see. Yes, that's odd.

I'd rather figure out why this fix fixes things for you. Since colorspace converting to itself should do no conversion whatsoever? As such, which other plug-in is 'misconfiguring' things then? 🤔 Perhaps you can try storing the input image and output image of this plug-in. Is it 1:1 the same? or does it differ? or why does it differ if it has same colorspace, etc.?

Some hosts have colorspace_data while some not.
I assume the best approach should be adding the relevant data back in the host?

@BigRoy

BigRoy commented Jul 7, 2026

Copy link
Copy Markdown
Member

@jakubjezek001 can you confirm this reasoning? It feels very odd that we're doing a transcode here that seems very focused on transcoding to the SAME resulting values? 🤔 Does it even need a transcode then hehe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community Issues and PRs coming from the community members size/XS type: bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants