BUGFIX: display and view not in colorspace_data, falls back on colorspace#1910
BUGFIX: display and view not in colorspace_data, falls back on colorspace#1910splidje wants to merge 2 commits into
Conversation
…olorspace for target colorspace. Also added plate product base type to families.
|
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? |
|
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. |
|
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. |
|
@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? |
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.