View Bug Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001123||DCP-o-matic||[All Projects] Bugs||public||2017-08-29 14:35||2017-09-01 20:03|
|Platform||Mac||OS||OS X||OS Version||10.11|
|Target Version||2.12.0||Fixed in Version|
|Summary||0001123: DPX log vs. lin interpretation looks faulty?|
In DOM 2.10.5, it looks as if log DPX files were interpreted as linear. This was fixed after it came up in this thread:
However, now it appears that in 2.11.19, linear DPX files are interpreted as log DPX files.
|Tags||No tags attached.|
|Estimated work required||Unknown|
hacks/dumpdpx.py shows Rajeev's linear DPXs as being marked "printing density" and the previous log DPX files that I had are marked as "logarithmic". ImageMagick returns LogColorspace for both these header values (see coders/dpx.c). I'm not sure who's wrong here but it looks like we need to make it a manual switch in DoM.
At the moment if we see LogColorspace in an image we call colorSpace to set it back to RGBColorspace. This calls TransformColorSpace which modifies the image; on reflection it looks like we should always do that. But in Rajeev's case it's the wrong thing to do, which is odd as the image being returned from MagickProxyImage::image is always marked as RGB.
I'm hopeful that c0e4fd517192ac25c4aedc406a8a490663ec58b6 (in 2.11.20) helps with this.
I'm marking this as fixed in the hope that it is!
|2017-08-29 14:35||Carsten||New Bug|
|2017-08-30 21:12||carl||Target Version||=> 2.12.0|
|2017-08-30 22:16||carl||Note Added: 0001792|
|2017-08-30 22:23||carl||Note Added: 0001793|
|2017-09-01 20:00||carl||Note Added: 0001796|
|2017-09-01 20:03||carl||Assigned To||=> carl|
|2017-09-01 20:03||carl||Status||new => resolved|
|2017-09-01 20:03||carl||Resolution||open => fixed|
|2017-09-01 20:03||carl||Note Added: 0001797|