I am running ufraw from cvs and gimp from git master. The most recent git pull for gimp has left me unable to open a nef file in ufraw, and then click on the gimp icon / button in ufraw to open the file in gimp
The console / command line message is: (file-svg:16335): GLib-WARNING **: (gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)
Gimp report from within the program: Opening '/tmp/dsc_3202.nef_I2XVWW.ufraw' failed: Could not open '/tmp/dsc_3202.nef_I2XVWW.ufraw' for reading: Unknown reason
I can open the raw file in ufraw, save as a png, and then open in gimp.
John K. Herreshoff
I have the same problem running on Debian with ufraw 0.19.2 (from the dhor PPA)
I have attached a file with version info and a backtrace.
same problem, fedora 18 x86_64 - today fresch guild (ufraw, gimp, gegel, babl) test with: NEF from Nikon1 and D700
and gimp-plugin don't work too
Last edit: Jaroslav Tvrdy 2013-06-12
Where is problem ?
Some big change in gimp ?
I am try open RAW from Nikon, Nikon1 and CR2 (canon)
Canon - dialog for 3 pages TIFF (like import PS/PDF) ... but empty.
ufraw -> send to gimp ... gimp save only ufraw config file to /tmp, not image ...
tested with all updated 6.7.2013 (all fresch GIT + CSV ufraw)
GNU Image Manipulation Program version 2.9.1
git-describe: soc-2012-unified-transform-after-gsoc-1098-g09682d6
using GEGL version 0.3.0 (compiled against version 0.3.0)
using GLib version 2.36.3 (compiled against version 2.36.3)
using GdkPixbuf version 2.28.2 (compiled against version 2.28.2)
using GTK+ version 2.24.19 (compiled against version 2.24.19)
using Pango version 1.34.1 (compiled against version 1.34.1)
using Fontconfig version 2.10.93 (compiled against version 2.10.93)
using Cairo version 1.12.14 (compiled against version 1.12.14)
ufraw --version
ufraw 0.20
EXIV2 enabled.
JPEG enabled.
JPEG2000 (libjasper) enabled.
TIFF enabled.
PNG enabled.
FITS enabled.
ZIP enabled.
BZIP2 enabled.
LENSFUN enabled.
Which was the latest GIMP version (date of git pull) that worked?
Regards,
Niels Kristian
The problem started back in May. I think it was with this patch: Author: Michael Natterer mitch@gimp.org 2013-05-02 14:50:29
app: fix file magic matching
HTH.
That ufraw worked as a GIMP plug-in (which is how "Send image to GIMP" works, by saving a temporary
*.ufrawfile, which is a piece of XML telling the ufraw GIMP plug-in to load a certain file with certain settings) is a byproduct of the GIMP magic mechanism having been broken which made GIMP choose a file loader plugin by extension almost exclusively.The commit above fixes that, but in the course causes GIMP to call
file-svg-load(which registers itself for files beginning with "<?xml") instead offile_ufraw_load(which registers no magic(s)).Another symptom of this is that GIMP built from git-master uses
file-tiff-loadinstead offile_ufraw_loadforNEFandARWfiles because their format seems to be built on the basicTIFFstructure (indeed, ImageMagick's "display" command displays myNEFandARWtest files just fine, but the GIMPTIFFloader seems to be more strict).I've managed to patch this latter case up by registering
file_ufraw_loadfor the same magic values:However, adding the XML magic as well doesn't repair "Send image to GIMP" for me. I suspect that if two loader procedures register themselves for the same magic, it's kind of a coin toss which one gets selected.
Oddly enough, meanwhile registering the appropriate magic values for the file load procedure works: ARW or NEF gets loaded by ufraw, TIF by file-tif-load, passing images from the standalone app to ufraw works as well. I'll attach the patches needed for that, please apply so the next version can deal with the upcoming GIMP versions.
Patches adding TIFF and XML magic necessary for development and future stable versions of GIMP.
Thanks for the patches. I have commited them to the cvs repository and close this bug report. Please reopen it if the problem is not completely fixed.
Regards,
Niels Kristian
The problem still occurs with the latest gimp/gegl git-master, and the problem is in gimp. The transfer to gimp does not work, and if I find the file in my /tmp directory (.ufraw) and try to open it, it does not open, BUT* if on the open dialog I click the drop down box for 'Select File Type,' and then select raw, which includes 'ufraw,' the file opens. The 'Select File Type' does not work automatically; it needs to be told what to open.
HTH.
John.
It's still not fixed with this patch. Try opening a SVG file and I get the message ufraw - unknown file type.