GNOME Bugzilla – Bug 603352
CR2 RAW colors are wrong
Last modified: 2012-07-31 19:11:41 UTC
When viewing CR2 RAW images with eog the colours are wrong (it seems a bit too green) I have linked an image (because it is 11.2MB) instead uploading: http://plaes.org/files/2009-Q4/IMG_8535.CR2 IIRC, this is a regression since 2.26.x because it used to display these images correctly.
Created attachment 148724 [details] ufraw-vs-eog.png Comparison between ufraw and eog.
This looks like a bug in libopenraw (or it's gdk-pixbuf component) as it works when I send the file through the TIFF loader. Please report the bug on freedesktop.org. ----------------------------------------------------------------------------- Thanks for taking the time to report this bug. However, this application does not track its bugs in the GNOME Bugzilla. We kindly ask you to report the bug to the application authors. For a selective list of other bug tracking systems please consult http://live.gnome.org/Bugsquad/TriageGuide/NonGnome. If the affected third party application has a bug tracking system you should investigate whether a bug for the reported issue is already filed in this system. If it has not been filed yet please do so. Also ensure that both bug reports contain a link to each other. Thanks in advance!
I'm going to reopen this, as it is clearly not a libopenraw bug but it's the fault of some other GNOME component... EOG with libopenraw used to work (as I fixed a big memleak on libopenraw side) a while ago and then the images looked fine (and there's not much changed since). Felix, do you have any other ideas of what might be wrong?
I took into it today and the result is that it occurs even with libopenraw's own pixbufload demo. So it's unlikely that it's eog's fault. Intercepting the data that libopenraw outputs before it gets fed into gdk-pixbuf shows that gdk-pixbuf does nothing color-wise to the data. So I guess it's a problem of libopenraw or one if it's dependencies (Boost?). Another observation: The data output by libopenraw is slightly larger than the one from Imagemagick. Using your picture ImageMagick produces a 2602x3906 image, but libopenraw's output is 3948x2622 (it's not rotated) producing borders above, below (really tiny) and to the left of the actual image. Maybe there's an offsetting problem somewhere. I also thought it could due to running on 64bit. But it also happens using a manually compiled libopenraw on the 32bit editions (they ship neither the demo nor the plugin in their stock packages) of Fedora12 and Ubuntu Karmic running in a VM.
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it. Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
This is still the case. But as far as I understand the comments in the fd.o bug this is a limitation of libopenraw right now. So let's close this as NOTGNOME. We can reopen this if necessary.