I ran into an issue with gtkimageview in pkgsrc, and it seesm upstream
is dead. Can anyone point me to a maintained version of this package,
preferably with a valid homepage, donwload site, and release that does
not fail with deprecated functions?
signature.asc
Description: PGP signature
Niels Kristian Bech Jensen writes:
> > Yes, that's what I'm doing, RAW+JPG. So I could compare pixels in any
>> pair of files shot that way. Except the size isn't exact. The JPEGs
>> are 6000x4000, the nefs are 6036x4020.
> There is also some in-camera lens distortion correction in the JPEG
Also, note that in Nikon at least, you can shoot RAW+JPG. SO you can
just compared raw->jpg with camera jpg, just bits.
pgpLzHRaSvB5m.pgp
Description: PGP signature
--
___
ufr
Alan Corey writes:
> I did a little playing with dcraw to tiff and ppm and I was shocked at
> how different they are from the jpegs. I would think shooting color
> ramps, measuring, and fitting the results to curves might be close to
> what you're talking about.
Keep in mind that different !=
Alan Corey writes:
> OK, never mind. I thought the white balance settings were getting
> reset between one RAW file and the next but I tried it again and they
> don't. So as Greg says I can load a gray card image, use the
> eyedropper, hit Cancel and load the real image. So my programming for
Alan Corey writes:
> I've been doing digital photography (amateur) for about 15 years but
> finally bought a Nikon D5200 so I can have RAW files. I've been
> programming on and off since 1968, got introduced to graphics through
> doing scientific plotting. I'm a retired network administrator,
It seems we had a patch for a CVE, and I wonder if we are in shape to
just cut a release. pkgsrc has a freeze starting 6/15ish, which is
motivating my question.Of course I can just carry the patch for the
issue.
(Yes, I'm still out here, and still use ufraw, but have too many things
to do.)
Udi Fuchs writes:
Since this didn't seem likely to get resolved correctly, I have used
DIST_SUBDIR in pkgsrc, which lets a recorded hash be associated with a
(local) storage location. This ensures that the old copy (same name,
different bits) will not be checked for hash corectness and fail.
I
Thanks for the explanation.
Could you bump to 0.19.3 and re-release? Otherwise packaging systems
have to kludge around having two files with the same name but different
contents out there. (0.19.2 would still have the issue, but it would
become irrelevant.)
pgpoTZvJqUMBe.pgp
Description: PGP
I updated pkgsrc and recorded this SHA1 and size:
$NetBSD: distinfo,v 1.28 2013/03/26 12:22:42 gdt Exp $
SHA1 (ufraw-0.19.2.tar.gz) = 6ff3a4a8b36f6060710aeee93a200a27ed9032d7
RMD160 (ufraw-0.19.2.tar.gz) = c83f73e27e3fff93889e51e46b697468ac856800
Size (ufraw-0.19.2.tar.gz) = 984672 bytes
Graham Inggs writes:
> Thanks, that knocks about 30% off the size of the tarball.
>
> I should have been clearer in my first message.
> Building with Debian's dh-autoreconf produces a list of unexpected
> changes. These are normally a sign that the build did not clean up
> properly.
> When I bu
There are two flavors of generated files, more or less for tools the
users are expected to have (and documented to require!), and for tools
they are not expected to have.
So I'm not sure about po/*.gmo. The other two perhaps should not be
present.
pgpsyjrVJJEzi.pgp
Description: PGP signature
-
With my pkgsrc ufraw maintainer hat, I got a bug report:
http://gnats.netbsd.org/47642
which has two patches for Solaris (said to have been sent "upstream",
which is here, but I haven't found them). I have copied the submitter
in hopes of speeding the resolution.
The first patch is casts an un
Niels Kristian Bech Jensen writes:
> Currently UFRaw support GIMP 2.2.0 and newer. Is it time to raise the
> minimum to e.g. GIMP 2.6.0 (released in January 2008) when we begin
> working on UFRaw 0.20? Are there supported systems/distributions out
> there that still use GIMP 2.2.x or 2.4.x? Rega
Niels Kristian Bech Jensen writes:
>> Considering the harm it can cause, I think it would be better not to
>> try and open these files. I think that we might want to take a further
>> step and also ignore tif and jpg endings. These raw files come from
>> very old cameras. I don't think anyone w
Martin Ling writes:
> -ffast-math:
>
> "This option is not turned on by any -O option besides -Ofast, since it
> can result in incorrect output for programs that depend on an exact
> implementation of IEEE or ISO rules/specifications for math functions.
> It may, however, yield faster code for p
Udi Fuchs writes:
> The long overdue release of UFRaw 0.19 if finally out. This is a
> maintenance release with lots of bug fixes and support for all recent
> cameras, thanks to dcraw 9.17.
I have updated pkgsrc, and verified that this runs fine on NetBSD 5,
i386, with a D200 .nef. Thanks for
That image runs fine for me on NetBSD 5 i386 with ufraw 0.19. But it
didn't have a lens correction type (my lensfun is old). I didn't
evaluate the color patch accuracy, but image quality looks very nice,
impressively so for a non-DSLR:-)
gtkimageview-1.6.4nb13:
gtk2+-2.24.14
gdk-pixbuf2-2.26.5
I just updated pkgsrc to lensfun 0.2.7. (I had to work around the shlib
naming issue.)
With that, and ufraw 0.19, I was able to process your image with no
issues, even after manually selecting the 30mm pancake lens and 5th
order lens model. This was on netbsd-5, i386.
I also filed a lensfun bu
Does ufraw (release, cvs?) work with gimp 2.8? I just saw a bug report
in pkgsrc after gimp was updated.
pgpp5uf4hL4yT.pgp
Description: PGP signature
--
Live Security Virtual Conference
Exclusive live event will cover a
Pascal de Bruijn writes:
> On Mon, Apr 23, 2012 at 5:39 PM, Greg Troxel wrote:
>>
>> I have a Rebel T3, exif data for my camera are 'EOS REBEL T3', not 'EOS
>> DIGITAL REBEL T3'. After patching wb_presets.c, I can use wb presets in
>> ufra
I have a Rebel T3, exif data for my camera are 'EOS REBEL T3', not 'EOS
DIGITAL REBEL T3'. After patching wb_presets.c, I can use wb presets in
ufraw.
Are you sure that there are no cameras that identify as "EOS DIGITAL
REBEL T3"?
pgpnAQ7jmxG80.pgp
Description: PGP signature
Martin Ling writes:
> On Sat, Feb 20, 2010 at 11:27:28PM +0100, Pascal de Bruijn wrote:
>>
>> When I apply UFRaw's internal 'Color Matrix' with gamma/linearity 1/1
>> I get a darkish image, and when I apply my color profile (which in
>> essence is only a color matrix as well), with gamma/linea
Frank van Maarseveen writes:
> Moving the crop area around no longer works: the preview screen is
> not updated (zoom-in/out updates it).
I saw lossage in cropping also, with cvs from last night.
pgp460dhqEPZF.pgp
Description: PGP signature
---
That seems reasonable, but to have a release we need a feature freeze.
He emphasized the importance of time base releases, which are not
bound by any specific feature. This seems to contradict my plans for
ufraw-0.17, which are centered around getting lensfun ready.
Aiming for a release ev
Alexandre Prokoudine writes:
> Which is why the question: while I don't expect you to merge with
> Darktable (oh, do I? :)), what is your official position regarding
> switch to libraw?
"official position" No one speaks for the coalition.
pgpke3ipwWmq2.pgp
Description: PGP signature
It looked like the "fogginess" was a result of problems in LCMS, most
likely related to limited precision arithmetic. I found similar issues
in ArgyllCMS, which went away if I used its floating point math
options.
Very interesting, and thank you for explaining this again. I had
managed n
Jos De Laender writes:
> 3. In dcraw everything is linear, based on the matrices. Until the
> moment the file is written and where something interesting occurs.
> At writing out BT709 gamma is used, rather than sRGB. However, viewers
> simply do not take into account BT709 gamma , but sRGB.
> So
Udi Fuchs writes:
> Yet all this has nothing to do with the original mail by Hadmut that
> started this thread. UFRaw should be able to save per camera settings
> regardless of the gamma issue. Actually there is a group of setting
> that is regarded as "camera settings" and all these settings sh
Pascal de Bruijn writes:
I am only 95% sure of what I'm saying here, so please point out any
specific errors.
The thing I am most unclear of is whether the 12-bit or 14-bit raw space
has had any encoding applied to it, although it seems not. (There's
compression, but that's different.)
> Also
Pascal de Bruijn writes:
> On Mon, 2009-04-06 at 18:54 +0100, Martin Ling wrote:
>> On Mon, Apr 06, 2009 at 06:27:24PM +0200, Pascal de Bruijn wrote:
>> >
>> > What does serial number have to do with this?
>>
>> Theoretically, one might use have two camera bodies of the same model
>> and have
It's already in TODO:
* Automatic profile selection based on camera model and serial#.
I think this should include the choice of color matrix vs a real
profile, and also set gamma/linear.
As for the gamma/linearity settings, there are specified values for
sRGB, and our defaults are different.
Martin Ling writes:
> I usually enable both automatic exposure and automatic black point in my
> .ufrawrc, as these tend to get a reasonable result first time for most
> photos.
>
> I've just noticed that if I then adjust the exposure, the black point
> doesn't change, although the auto black p
This discussion of Apical, which is apparently what D-Lighting really
is, was quite interesting - I've often had trouble adjusting images with
a single tone curve.
http://www.dpreview.com/news/0903/09031801apical.asp
pgpv9Gbk2fdY0.pgp
Description: PGP signature
-
Udi Fuchs writes:
> I'm considering making the GtkImageView library mandatory for building UFRaw.
>
> Having this build option requires too many #ifdef's in the code, and I
> don't maintain the code without GtkImageView.
>
> Any objections?
My previous note was ambiguous - so to make things cle
Udi Fuchs writes:
> I'm considering making the GtkImageView library mandatory for building UFRaw.
>
> Having this build option requires too many #ifdef's in the code, and I
> don't maintain the code without GtkImageView.
>
> Any objections?
Well, I see your point, but I am not sure that GtkImag
the attached patch improves the configure script from a distribution
point of view, as you may disable automagic dependencies for some
packages. the behaviour of just running ./configure will stay the same
(checking if the packages are available).
I applied this patch to the gentoo porta
37 matches
Mail list logo
