Ufraw fix:
Download and compile dcraw current:
http://www.cybercom.net/~dcoffin/dcraw/
using
http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
and from that URL,
gcc -o dcraw -O4 dcraw.c -lm -DNODEPS
works on SL6x
Next,
Download and install into gimp the file rawphoto.c
http://www.cybercom.net/%7Edcoffin/dcraw/rawphoto.c
After installing "dcraw", do "gimptool --install rawphoto.c
You will need to have installed the rpm containing gimptool; this can be
gotten through the standard add/remove software GUI tool under System
--> Administration from the top bar of the standard gnome GUI.
Note:
From the dcraw URL:
My plugin provides a simple dialog box for loading raw files into the
Gimp. Udi Fuchs and Joseph Heled have written much nicer plugins, with
live preview, histograms, and color curves.
End quote. If someone has the time, one may try to build the current
ufraw (the Udi Fuchs gimp plugin mentioned above), either from the
src.rpm or from
http://ufraw.sourceforge.net/
At the moment, the dcraw workaround seems to be functioning for our
immediate need; however, I would appreciate the current (latest
production source) ufraw plugin if this is available. Also, if someone
finds the Joseph Heled plugin and can build it, this might be a
worthwhile comparison.
Yasha Karant
On 06/17/2013 08:45 AM, Yasha Karant wrote:
On 06/17/2013 07:07 AM, David Sommerseth wrote:
On 16/06/13 17:31, Akemi Yagi wrote:
On Sun, Jun 16, 2013 at 7:52 AM, Yasha Karant <[email protected]> wrote:
I need the current ufraw plugin plus support files for gimp.
I could find: ufraw-0.19.2-2.fc17.1 rpm
for Fedora 17, but this will not install into SL 6x . According to the
ufraw URL, the above ufraw release does support the raw digital image
formats we need.
Yasha Karant
NuxRo's repo has ufraw 0.18-2:
http://pkgs.org/search/?keyword=ufraw
If you need 0.19, try compiling it from the fc17 source. There might
be some dependency issue though.
Just what I would suggest as well. Pull down the src.rpm package and do:
$ rpmbuild --rebuild $SRC_RPM
This will be some iterations to get proper -devel packages installed.
But if you start to need other source packages, then it will be
considerably harder - as that may break your SL installation if you
update some commonly shared libraries.
--
kind regards,
David Sommerseth
Let me approach this general issue from a different point. None of the
linux systems designs easily enable proper encapsulation and
polymorphism, as the above comment illustrates (that may break your SL
installation if you update some commonly shared libraries, end quote).
Can one build an application (in this case, GIMP "plug in") to use only
static libraries within a unique build tree that does not overlap with
the standard SL installation?
Unless the incompatibility is at the kernel, Xwindows, etc., API level,
then a fully static (in open systems parlance, not .so, but .a
libraries) implementation should work. Such a static image could
require considerably more memory (both RAM for execution as well a mass
storage for the image), but should not interfere with the standard SL
(SL Nx, currently N = 6).
If such a static "isolated" build is possible within SL, are there any
tools/packages/scripts that more easily enable such an approach?
Yasha Karant
