You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(15) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(32) |
Feb
(22) |
Mar
(12) |
Apr
(1) |
May
|
Jun
(4) |
Jul
(2) |
Aug
(23) |
Sep
(5) |
Oct
(6) |
Nov
(6) |
Dec
(1) |
2007 |
Jan
(8) |
Feb
(9) |
Mar
(16) |
Apr
(36) |
May
(43) |
Jun
(26) |
Jul
(39) |
Aug
(8) |
Sep
(20) |
Oct
(35) |
Nov
(9) |
Dec
(47) |
2008 |
Jan
(22) |
Feb
(19) |
Mar
(156) |
Apr
(91) |
May
(120) |
Jun
(22) |
Jul
(37) |
Aug
(18) |
Sep
|
Oct
(10) |
Nov
(2) |
Dec
(29) |
2009 |
Jan
(17) |
Feb
(24) |
Mar
(21) |
Apr
(22) |
May
|
Jun
(5) |
Jul
(49) |
Aug
(48) |
Sep
(74) |
Oct
(92) |
Nov
(149) |
Dec
(2) |
2010 |
Jan
(32) |
Feb
(74) |
Mar
(58) |
Apr
(30) |
May
(11) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
(12) |
Oct
(3) |
Nov
(15) |
Dec
(1) |
2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(8) |
May
(1) |
Jun
(14) |
Jul
(4) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(1) |
2012 |
Jan
(3) |
Feb
(1) |
Mar
(4) |
Apr
(5) |
May
(5) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(3) |
2013 |
Jan
(2) |
Feb
(5) |
Mar
(71) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(12) |
Nov
|
Dec
|
2014 |
Jan
(8) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(6) |
Jun
(5) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(10) |
Nov
|
Dec
(2) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alan C. <ala...@gm...> - 2017-05-27 18:27:11
|
> > you already have ufraw version 0.22 > No, I guess I'm waiting for that to make its way through Debian and Raspbian ports. This is 0.20. I'll go back to bugging raspberrypi.org. Of course I could build it from source, but it's just as easy to import it to Gimp upside down and rotate it there. I do crop in Ufraw sometimes if there's something black in the border that might affect the black level. I hadn't looked to see if it was the latest. I do apt-get update and apt-get upgrade once a month, that should eventually replace it. |
From: Sérgio B. <se...@se...> - 2017-05-25 10:26:09
|
you already have ufraw version 0.22 On Sat, 2017-05-20 at 12:16 -0400, Alan Corey wrote: > I'm not sure how to document it best. I have a Nikon D5200 which I > was using on a tripod with the center column inverted taking pictures > of flowers near the ground. In Ufraw I go into the crop/rotate > screen > to rotate it. CW or CCW the same thing happens. I rotate 90 degrees > and it's fine. Rotate another 90 (or rotate it back) and it > segfaults. > > /usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Segmentation > fault > > I don't want to flip it 180 and have a mirror image, I want to rotate > it 180. > > This is gimp-ufraw 0.20-2+deb8u1 on a Raspberry Pi (Linux pi2 > 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux). > I've never seen it happen under OpenBSD. Raspbian doesn't normally > leave core files unless you do "ulimit -c unlimited" so I did that > and > I still couldn't find a core file. It probably wasn't compiled with > debug symbols on anyway, I'm just using a binary deb. I've tried the > same thing on pictures that were taken without the camera upside down > and they rotate fine. I reported it on the Raspberry Pi forum and > they said report it here. The raw files are like 25 megabytes, too > big to email. > > Is there a camera orientation field in makernotes or something and it > isn't handled well? > > > -- > ------------- > No, I won't call it "climate change", do you have a "reality > problem"? - AB1JX > Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeac > h > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel -- Sérgio M. B. |
From: Alan C. <ala...@gm...> - 2017-05-20 16:16:17
|
I'm not sure how to document it best. I have a Nikon D5200 which I was using on a tripod with the center column inverted taking pictures of flowers near the ground. In Ufraw I go into the crop/rotate screen to rotate it. CW or CCW the same thing happens. I rotate 90 degrees and it's fine. Rotate another 90 (or rotate it back) and it segfaults. /usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Segmentation fault I don't want to flip it 180 and have a mirror image, I want to rotate it 180. This is gimp-ufraw 0.20-2+deb8u1 on a Raspberry Pi (Linux pi2 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux). I've never seen it happen under OpenBSD. Raspbian doesn't normally leave core files unless you do "ulimit -c unlimited" so I did that and I still couldn't find a core file. It probably wasn't compiled with debug symbols on anyway, I'm just using a binary deb. I've tried the same thing on pictures that were taken without the camera upside down and they rotate fine. I reported it on the Raspberry Pi forum and they said report it here. The raw files are like 25 megabytes, too big to email. Is there a camera orientation field in makernotes or something and it isn't handled well? -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach |
From: Sérgio B. <se...@se...> - 2017-05-17 10:50:30
|
On Wed, 2017-05-17 at 04:23 +0100, Ken Moffat wrote: > On Wed, May 17, 2017 at 03:21:13AM +0100, Ken Moffat wrote: > > > > The attached patch (not sure if attachments on this list are > > visible > > in the archives, so I'll spell it out: at line 8769 delete i and c > > from unsigned, add them to int on the following line) builds. > > > > Might help if I actually attach it. Hi, we have this patch, same kind of problem (using const signed ) https://src.fedoraproject.org/cgit/rpms/ufraw.git/tree/05_fix_build_due_to_unsigned_char.patch I will check (this evening ) if ufraw compiles with GCC 7.1 Cheers, -- Sérgio M. B. |
From: Ken M. <zar...@nt...> - 2017-05-17 03:23:15
|
On Wed, May 17, 2017 at 03:21:13AM +0100, Ken Moffat wrote: > > The attached patch (not sure if attachments on this list are visible > in the archives, so I'll spell it out: at line 8769 delete i and c > from unsigned, add them to int on the following line) builds. > Might help if I actually attach it. -- I live in a city. I know sparrows from starlings. After that everything is a duck as far as I'm concerned. -- Monstrous Regiment |
From: Ken M. <zar...@nt...> - 2017-05-17 02:21:22
|
Hi, I saw the news from Niels in December, so in the absence of a current maintainer I'm posting this here. I've just moved to gcc-7.1 and dcraw.cc no longer compiles - dcraw.cc:9245:16: error: call of overloaded 'abs(unsigned int&)' is ambiguous if (abs(i) < abs(c)) { The attached patch (not sure if attachments on this list are visible in the archives, so I'll spell it out: at line 8769 delete i and c from unsigned, add them to int on the following line) builds. I've no idea what sort of camera this is for (possibly an Olympus), so I wasn't looking forward to testing this, but I see that Dave Coffin has now updated dcraw.c to 9.27 and his code seems to match this change. This also seems to work with both of my Olympuses, which may or may not be relevant. ĸen -- I live in a city. I know sparrows from starlings. After that everything is a duck as far as I'm concerned. -- Monstrous Regiment |
From: Sérgio B. <se...@se...> - 2016-10-25 23:47:18
|
Hello , why cvs ? I need to find 2 patches, cvs is from stone age so what I did ? cvs -d:pserver:ano...@uf...:/cvsroot/ufraw login cvs -z3 -d:pserver:ano...@uf...:/cvsroot/ufraw co -P ufraw cd ufraw git cvsimport -v ( I waited about 3 or 6 hours) In github.com press + and new repository, choose repository name: ufraw without "Initialize this repository with a README" . and run: git remote add origin gi...@gi...:sergiomb2/ufraw.git git push -u origin master and I got this : https://github.com/sergiomb2/ufraw/commits/master and I can see lots of commits and lots of work ! Updates of dcraw.cc and iccjpeg.c , I'm trying to fix https://sourceforge.net/p/ufraw/bugs/406/ and after analysing commits seems to me https://github.com/sergiomb2/ufraw/commit/fbe5344a62715a9ef542d5bca8525a89e5d85be3 can fix some of the problems described in ticket ? Thanks, -- Sérgio M. B. |
From: Pascal de B. <pmj...@pc...> - 2016-10-05 16:59:46
|
On Mon, Aug 1, 2016 at 10:54 PM, Alan Corey <ala...@gm...> wrote: > I'm just playing with Hugin, initially lured by the mention of doing > focus stacking but I'd like to do some panoramas too. When stitching > images together it's important that they've had as close to the same > processing as possible. I guess you avoid partly cloudy days. > > I don't know if there's a way to make dcraw do this, it seems like it > would have to read all the input files (there may be 100 or so for > focus stacking) to find the brightest point then process all the files > to match. That would take huge amounts of memory, so storing > statistics in a file during a first pass then making a second pass > once it knows what to do would seem to be the best approach. My > initial results from just converting to tiff individually then working > with those haven't been bad, I just wondered if there's a more proper > way to do it. > > Oh, and Hugin doesn't actually do much with focus stacking, but > align_image_stack which comes with it and enfuse to blend them seems > to be the way to go. So even if libraw has a multi-image capability I > don't think align_image_stack uses it (or imports raws). > > I've got a first focus stack (only 5 images) at > https://images.nikonians.org/galleries/data/26892/fused2.jpg UFRaw can output a .ufraw file (with the settings you used), which can be passed to ufraw-batch... Also ufraw-batch is parameterizable :) Something like this should be workable: for NEF in *.NEF; do ufraw-batch --conf=my_first_image.ufraw --out-type=jpeg --output=$NEF.jpg $NEF Regards, Pascal de Bruijn |
From: Alan C. <ala...@gm...> - 2016-08-01 20:54:14
|
I'm just playing with Hugin, initially lured by the mention of doing focus stacking but I'd like to do some panoramas too. When stitching images together it's important that they've had as close to the same processing as possible. I guess you avoid partly cloudy days. I don't know if there's a way to make dcraw do this, it seems like it would have to read all the input files (there may be 100 or so for focus stacking) to find the brightest point then process all the files to match. That would take huge amounts of memory, so storing statistics in a file during a first pass then making a second pass once it knows what to do would seem to be the best approach. My initial results from just converting to tiff individually then working with those haven't been bad, I just wondered if there's a more proper way to do it. Oh, and Hugin doesn't actually do much with focus stacking, but align_image_stack which comes with it and enfuse to blend them seems to be the way to go. So even if libraw has a multi-image capability I don't think align_image_stack uses it (or imports raws). I've got a first focus stack (only 5 images) at https://images.nikonians.org/galleries/data/26892/fused2.jpg -- Credit is the root of all evil. - AB1JX |
From: Dave <dav...@gm...> - 2016-08-01 20:29:11
|
My issue does appear to be related to a know exiv2 bug. However that bug was supposedly fixed and it appears to me that I have the latest version of exiv2. Does the info below reveal any packaging issue or anything else I should alert the Arch ufraw maintainer or packager about? Thanks (and forgive me if it is not appropriate to continue the conversation here). Bug #1584853 “Shotwell crashes on startup / Crash in exiv2 due t...” : Bugs : exiv2 package : Ubuntu https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1584853 Bug 765963 – assert in exiv2 when writing metadata https://bugzilla.gnome.org/show_bug.cgi?id=765963 Bug #1106: Crash in exiv2 due to assertion when setting rating on jpg with a Casio makernote - Exiv2 http://dev.exiv2.org/issues/1106 $ uname -a Linux myserver 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64 GNU/Linux $ exiv2 --version exiv2 0.25 001900 (64 bit build) $ ufraw --version ufraw 0.22 EXIV2 enabled. JPEG enabled. JPEG2000 (libjasper) enabled. TIFF enabled. PNG enabled. FITS enabled. ZIP enabled. BZIP2 enabled. LENSFUN enabled. On Mon, Aug 1, 2016 at 1:31 PM, Pascal de Bruijn <pmj...@pc...> wrote: > On Sat, Jul 30, 2016 at 10:37 PM, Dave T <dav...@gm...> wrote: > >> I'm running Arch Linux 64 bit. I installed this package today: >> >> Arch Linux - gimp-ufraw 0.22-7 (x86_64) >> https://www.archlinux.org/packages/comm … imp-ufraw/ >> <https://www.archlinux.org/packages/community/x86_64/gimp-ufraw/> >> >> install: >> >> $ sudo pacman -S gimp-ufraw >> >> run: >> >> ufraw /path/to/file.dng >> >> Error message: >> >>> ufraw: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed. >>> Aborted (core dumped) >>> >>> I would guess this is most likely an Exiv2 issue (in which case you'd > need to report the issue there), not per-se UFRaw... but... > > Does archlinux install debug symbols by default? Or do you need to install > ufraw-debug or ufraw-dbg package for that? If need be, please do so... then > try: > > gdb ufraw /path/to/file.dng > r > (do whatever it takes to make it crash) > bt > > and post the backtrace back here. > > Regards, > Pascal de Bruijn > > PS: As a sidenote, what is the source of the DNG file you're trying to > load? Is it straight from a DNG capable camera? Is it a DNG converted from > a RAW using Adobe's DNG Converter? Or is a DNG converter from a RAW using > an atrocious third party DNG converter? And what camera in particular is > the source of the original file? > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > > |
From: Dave <dav...@gm...> - 2016-08-01 20:10:45
|
Thanks for your reply. This is a DNG file straight from a DNG capable camera. In the past I worked with older versions of ufraw and gimp using the same camera. (I was on Kubuntu 12.04 then.) I recently started using Arch Linux. So far I do not find any ufraw package with debug symbols in the Arch repo. I'll ask them about that. I don't know if the following is of any help, but just in case here it is: $ gdb ufraw /path/to/file.DNG GNU gdb (GDB) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ufraw...(no debugging symbols found)...done. "/path/to/file.DNG" is not a core dump: File format not recognized (gdb) r Starting program: /usr/bin/ufraw [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffecfd1700 (LWP 10275)] (ufraw:10271): Gtk-WARNING **: Theme file for default has no name (ufraw:10271): Gtk-WARNING **: Theme file for default has no directories [New Thread 0x7fffe7fff700 (LWP 10276)] [New Thread 0x7fffe77fe700 (LWP 10277)] [New Thread 0x7fffe6824700 (LWP 10278)] [New Thread 0x7fffe6023700 (LWP 10279)] [New Thread 0x7fffe5822700 (LWP 10280)] [New Thread 0x7fffe5021700 (LWP 10281)] [New Thread 0x7fffe4820700 (LWP 10282)] [New Thread 0x7fffc1fcf700 (LWP 10283)] [New Thread 0x7fffc17ce700 (LWP 10284)] [New Thread 0x7fffc0fcd700 (LWP 10285)] [New Thread 0x7fffb7ffe700 (LWP 10286)] [Thread 0x7fffc0fcd700 (LWP 10285) exited] [Thread 0x7fffe77fe700 (LWP 10277) exited] [Thread 0x7fffb7ffe700 (LWP 10286) exited] [Thread 0x7fffe6824700 (LWP 10278) exited] [Thread 0x7fffe4820700 (LWP 10282) exited] [Thread 0x7fffe6023700 (LWP 10279) exited] [Thread 0x7fffe5822700 (LWP 10280) exited] [Thread 0x7fffc17ce700 (LWP 10284) exited] [Thread 0x7fffe7fff700 (LWP 10276) exited] ufraw: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed. Thread 1 "ufraw" received signal SIGABRT, Aborted. 0x00007ffff4017295 in raise () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff4017295 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff40186da in abort () from /usr/lib/libc.so.6 #2 0x00007ffff4010297 in __assert_fail_base () from /usr/lib/libc.so.6 #3 0x00007ffff4010342 in __assert_fail () from /usr/lib/libc.so.6 #4 0x00007ffff7a4f91e in ?? () from /usr/lib/libexiv2.so.14 #5 0x00007ffff7a4a072 in ?? () from /usr/lib/libexiv2.so.14 #6 0x00007ffff7a4ab07 in ?? () from /usr/lib/libexiv2.so.14 #7 0x00007ffff7a4a072 in ?? () from /usr/lib/libexiv2.so.14 #8 0x00007ffff7a4f5bb in ?? () from /usr/lib/libexiv2.so.14 #9 0x00007ffff7a4a072 in ?? () from /usr/lib/libexiv2.so.14 #10 0x00007ffff7a4ab07 in ?? () from /usr/lib/libexiv2.so.14 #11 0x00007ffff7a4a072 in ?? () from /usr/lib/libexiv2.so.14 #12 0x00007ffff7a67d9c in ?? () from /usr/lib/libexiv2.so.14 #13 0x00007ffff7a55f3d in ?? () from /usr/lib/libexiv2.so.14 #14 0x00007ffff79e75c6 in Exiv2::ExifParser::encode(std::vector<unsigned char, std::allocator<unsigned char> >&, unsigned char const*, unsigned int, Exiv2::ByteOrder, Exiv2::ExifData const&) () from /usr/lib/libexiv2.so.14 On Mon, Aug 1, 2016 at 1:31 PM, Pascal de Bruijn <pmj...@pc...> wrote: > On Sat, Jul 30, 2016 at 10:37 PM, Dave T <dav...@gm...> wrote: > >> I'm running Arch Linux 64 bit. I installed this package today: >> >> Arch Linux - gimp-ufraw 0.22-7 (x86_64) >> https://www.archlinux.org/packages/comm … imp-ufraw/ >> <https://www.archlinux.org/packages/community/x86_64/gimp-ufraw/> >> >> install: >> >> $ sudo pacman -S gimp-ufraw >> >> run: >> >> ufraw /path/to/file.dng >> >> Error message: >> >>> ufraw: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed. >>> Aborted (core dumped) >>> >>> I would guess this is most likely an Exiv2 issue (in which case you'd > need to report the issue there), not per-se UFRaw... but... > > Does archlinux install debug symbols by default? Or do you need to install > ufraw-debug or ufraw-dbg package for that? If need be, please do so... then > try: > > gdb ufraw /path/to/file.dng > r > (do whatever it takes to make it crash) > bt > > and post the backtrace back here. > > Regards, > Pascal de Bruijn > > PS: As a sidenote, what is the source of the DNG file you're trying to > load? Is it straight from a DNG capable camera? Is it a DNG converted from > a RAW using Adobe's DNG Converter? Or is a DNG converter from a RAW using > an atrocious third party DNG converter? And what camera in particular is > the source of the original file? > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > > |
From: Pascal de B. <pmj...@pc...> - 2016-08-01 17:49:17
|
On Sat, Jul 30, 2016 at 10:37 PM, Dave T <dav...@gm...> wrote: > I'm running Arch Linux 64 bit. I installed this package today: > > Arch Linux - gimp-ufraw 0.22-7 (x86_64) > https://www.archlinux.org/packages/comm … imp-ufraw/ > <https://www.archlinux.org/packages/community/x86_64/gimp-ufraw/> > > install: > > $ sudo pacman -S gimp-ufraw > > run: > > ufraw /path/to/file.dng > > Error message: > >> ufraw: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed. >> Aborted (core dumped) >> >> I would guess this is most likely an Exiv2 issue (in which case you'd need to report the issue there), not per-se UFRaw... but... Does archlinux install debug symbols by default? Or do you need to install ufraw-debug or ufraw-dbg package for that? If need be, please do so... then try: gdb ufraw /path/to/file.dng r (do whatever it takes to make it crash) bt and post the backtrace back here. Regards, Pascal de Bruijn PS: As a sidenote, what is the source of the DNG file you're trying to load? Is it straight from a DNG capable camera? Is it a DNG converted from a RAW using Adobe's DNG Converter? Or is a DNG converter from a RAW using an atrocious third party DNG converter? And what camera in particular is the source of the original file? |
From: Dave T <dav...@gm...> - 2016-07-30 20:37:36
|
I'm running Arch Linux 64 bit. I installed this package today: Arch Linux - gimp-ufraw 0.22-7 (x86_64) https://www.archlinux.org/packages/comm … imp-ufraw/ <https://www.archlinux.org/packages/community/x86_64/gimp-ufraw/> install: $ sudo pacman -S gimp-ufraw run: ufraw /path/to/file.dng Error message: > ufraw: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed. > Aborted (core dumped) > > $ exiv2 --version exiv2 0.25 001900 (64 bit build) Copyright (C) 2004-2015 Andreas Huggel. Is this the best place to get support for ufraw for issues like this? |
From: Frank v. M. <fr...@fr...> - 2016-07-30 11:26:59
|
The conversion of RGB channel multipliers to Temperature/Green values cannot be done without loosing information. Therefore, the RGB values should prevail over Temperature/Green when they are loaded from an ID file. diff --git a/ufraw.h b/ufraw.h index f143a68..6f037cc 100644 --- a/ufraw.h +++ b/ufraw.h @@ -407,7 +407,7 @@ void ufraw_invalidate_darkframe_layer(ufraw_data *uf); void ufraw_invalidate_despeckle_layer(ufraw_data *uf); void ufraw_invalidate_whitebalance_layer(ufraw_data *uf); void ufraw_invalidate_smoothing_layer(ufraw_data *uf); -int ufraw_set_wb(ufraw_data *uf); +int ufraw_set_wb(ufraw_data *uf, gboolean interactive); void ufraw_auto_expose(ufraw_data *uf); void ufraw_auto_black(ufraw_data *uf); void ufraw_auto_curve(ufraw_data *uf); diff --git a/ufraw_settings.cc b/ufraw_settings.cc index 185cb31..5076ec9 100644 --- a/ufraw_settings.cc +++ b/ufraw_settings.cc @@ -342,7 +342,7 @@ void Image::SetWB(const char *mode) } if (mode != NULL) wb.Set(mode); - ufraw_set_wb(uf); + ufraw_set_wb(uf, TRUE); if (wb.IsEqual(uf_spot_wb)) wb.Set(uf_manual_wb); } diff --git a/ufraw_ufraw.c b/ufraw_ufraw.c index 2245fb0..d15cd15 100644 --- a/ufraw_ufraw.c +++ b/ufraw_ufraw.c @@ -727,7 +727,7 @@ int ufraw_load_raw(ufraw_data *uf) UFObject *wbTuning = ufgroup_element(uf->conf->ufobject, ufWBFineTuning); double oldTuning = ufnumber_value(wbTuning); - ufraw_set_wb(uf); + ufraw_set_wb(uf, FALSE); /* Here ufobject's automation goes against us. A change in * ChannelMultipliers might change ufWB to uf_manual_wb. * So we need to change it back. */ @@ -2015,7 +2015,7 @@ void ufraw_invalidate_smoothing_layer(ufraw_data *uf) ufraw_invalidate_layer(uf, ufraw_first_phase); } -int ufraw_set_wb(ufraw_data *uf) +int ufraw_set_wb(ufraw_data *uf, gboolean interactive) { dcraw_data *raw = uf->raw; double rgbWB[3]; @@ -2032,38 +2032,40 @@ int ufraw_set_wb(ufraw_data *uf) /* For uf_manual_wb we calculate chanMul from the temperature/green. */ /* For all other it is the other way around. */ if (ufarray_is_equal(wb, uf_manual_wb)) { - double chanMulArray[4] = {1, 1, 1, 1 }; - Temperature_to_RGB(ufnumber_value(temperature), rgbWB); - rgbWB[1] = rgbWB[1] / ufnumber_value(green); - /* Suppose we shot a white card at some temperature: - * rgbWB[3] = rgb_cam[3][4] * preMul[4] * camWhite[4] - * Now we want to make it white (1,1,1), so we replace preMul - * with chanMul, which is defined as: - * chanMul[4][4] = cam_rgb[4][3] * (1/rgbWB[3][3]) * rgb_cam[3][4] - * * preMul[4][4] - * We "upgraded" preMul, chanMul and rgbWB to diagonal matrices. - * This allows for the manipulation: - * (1/chanMul)[4][4] = (1/preMul)[4][4] * cam_rgb[4][3] * rgbWB[3][3] - * * rgb_cam[3][4] - * We use the fact that rgb_cam[3][4] * (1,1,1,1) = (1,1,1) and get: - * (1/chanMul)[4] = (1/preMul)[4][4] * cam_rgb[4][3] * rgbWB[3] - */ - if (uf->raw_color) { - /* If there is no color matrix it is simple */ - if (uf->colors > 1) - for (c = 0; c < 3; c++) - chanMulArray[c] = raw->pre_mul[c] / rgbWB[c]; - ufnumber_array_set(chanMul, chanMulArray); - } else { - for (c = 0; c < uf->colors; c++) { - double chanMulInv = 0; - for (cc = 0; cc < 3; cc++) - chanMulInv += 1 / raw->pre_mul[c] * raw->cam_rgb[c][cc] - * rgbWB[cc]; - chanMulArray[c] = 1 / chanMulInv; - } - ufnumber_array_set(chanMul, chanMulArray); - } + if (interactive) { + double chanMulArray[4] = {1, 1, 1, 1 }; + Temperature_to_RGB(ufnumber_value(temperature), rgbWB); + rgbWB[1] = rgbWB[1] / ufnumber_value(green); + /* Suppose we shot a white card at some temperature: + * rgbWB[3] = rgb_cam[3][4] * preMul[4] * camWhite[4] + * Now we want to make it white (1,1,1), so we replace preMul + * with chanMul, which is defined as: + * chanMul[4][4] = cam_rgb[4][3] * (1/rgbWB[3][3]) * rgb_cam[3][4] + * * preMul[4][4] + * We "upgraded" preMul, chanMul and rgbWB to diagonal matrices. + * This allows for the manipulation: + * (1/chanMul)[4][4] = (1/preMul)[4][4] * cam_rgb[4][3] * rgbWB[3][3] + * * rgb_cam[3][4] + * We use the fact that rgb_cam[3][4] * (1,1,1,1) = (1,1,1) and get: + * (1/chanMul)[4] = (1/preMul)[4][4] * cam_rgb[4][3] * rgbWB[3] + */ + if (uf->raw_color) { + /* If there is no color matrix it is simple */ + if (uf->colors > 1) + for (c = 0; c < 3; c++) + chanMulArray[c] = raw->pre_mul[c] / rgbWB[c]; + ufnumber_array_set(chanMul, chanMulArray); + } else { + for (c = 0; c < uf->colors; c++) { + double chanMulInv = 0; + for (cc = 0; cc < 3; cc++) + chanMulInv += 1 / raw->pre_mul[c] * raw->cam_rgb[c][cc] + * rgbWB[cc]; + chanMulArray[c] = 1 / chanMulInv; + } + ufnumber_array_set(chanMul, chanMulArray); + } + } ufnumber_set(wbTuning, 0); return UFRAW_SUCCESS; } @@ -2174,7 +2176,7 @@ int ufraw_set_wb(ufraw_data *uf) ufnumber_array_set(chanMul, wb_preset[lastTuning].channel); } else { ufobject_set_string(wb, uf_manual_wb); - ufraw_set_wb(uf); + ufraw_set_wb(uf, interactive); return UFRAW_WARNING; } } -- Frank |
From: Hartmut K. <kna...@gm...> - 2016-07-19 23:10:18
|
Please include these presets. It didn't seem as the camera would allow to fine-tune. Loading Canon PowerShot SX160 IS image from ... Day Light <ChannelMultipliers>1.725252 1.000000 1.444444 1.000000</ChannelMultipliers> Cloudy <ChannelMultipliers>1.843781 1.000000 1.359204 1.000000</ChannelMultipliers> Tungsten <ChannelMultipliers>1.103726 1.000000 2.322256 1.000000</ChannelMultipliers> Fluorescent <ChannelMultipliers>1.704705 1.000000 1.463463 1.000000</ChannelMultipliers> Fluorescent H <ChannelMultipliers>1.848423 1.000000 1.355036 1.000000</ChannelMultipliers> |
From: Hartmut K. <kna...@gm...> - 2016-07-18 22:09:04
|
Fix a copy-paste and accent typo in the spanish translation file for the --embedded-image option. Signed-off-by: Hartmut Knaack <kna...@gm...> --- Index: po/es.po =================================================================== RCS file: /cvsroot/ufraw/ufraw/po/es.po,v retrieving revision 1.142 diff -u -r1.142 es.po --- po/es.po 2 Jan 2016 16:00:21 -0000 1.142 +++ po/es.po 26 Jun 2016 11:56:47 -0000 @@ -57,7 +57,7 @@ #, fuzzy msgid "The --embedded-image option is only valid with 'ufraw-batch'" -msgstr "la opcion --silent solo es válida en modo por lotes" +msgstr "la opción --embedded-image solo es válida en modo por lotes" msgid "Raw images" msgstr "Imágenes RAW" |
From: Hartmut K. <kna...@gm...> - 2016-07-18 22:04:48
|
Add an option called noExit, which can be used to keep ufraw running, after a Raw development (save an image or import in the GIMP) has been carried out. This option is quite convenient, when only one or few parameters should be adjusted for a series of images, while keeping several others. For example in HDR processing, only exposure compensation might be changed, while lens-correction and geometry (size, cropping, scaling) should stay the same for each image. Signed-off-by: Hartmut Knaack <kna...@gm...> --- Index: ufraw.h =================================================================== RCS file: /cvsroot/ufraw/ufraw/ufraw.h,v retrieving revision 1.180 diff -u -r1.180 ufraw.h --- ufraw.h 2 Jan 2016 16:00:20 -0000 1.180 +++ ufraw.h 26 Jun 2016 12:03:55 -0000 @@ -284,7 +284,7 @@ char inputURI[max_path], inputModTime[max_name]; int type, compression, createID, embedExif, progressiveJPEG; int shrink, size; - gboolean overwrite, losslessCompress, embeddedImage; + gboolean overwrite, losslessCompress, embeddedImage, noExit; gboolean rotate; /* GUI settings */ Index: ufraw_conf.c =================================================================== RCS file: /cvsroot/ufraw/ufraw/ufraw_conf.c,v retrieving revision 1.204 diff -u -r1.204 ufraw_conf.c --- ufraw_conf.c 2 Jan 2016 16:00:20 -0000 1.204 +++ ufraw_conf.c 26 Jun 2016 12:03:57 -0000 @@ -115,6 +115,7 @@ FALSE, /* overwrite existing files without asking */ FALSE, /* losslessCompress */ FALSE, /* load embedded preview image */ + FALSE, /* noExit */ TRUE, /* rotate to camera's setting */ /* GUI settings */ @@ -762,6 +763,7 @@ if (!strcmp("Overwrite", element)) sscanf(temp, "%d", &c->overwrite); if (!strcmp("LosslessCompression", element)) sscanf(temp, "%d", &c->losslessCompress); + if (!strcmp("NoExit", element)) sscanf(temp, "%d", &c->noExit); } int conf_load(conf_data *c, const char *IDFilename) @@ -1114,6 +1116,8 @@ buf = uf_markup_buf(buf, "<LosslessCompression>%d</LosslessCompression>\n", c->losslessCompress); + if (c->noExit != conf_default.noExit) + buf = uf_markup_buf(buf, "<NoExit>%d</NoExit>\n", c->noExit); for (i = 0; i < c->BaseCurveCount; i++) { char *curveBuf = curve_buffer(&c->BaseCurve[i]); /* Write curve if it is non-default and we are not writing to .ufraw */ @@ -1477,6 +1481,7 @@ dst->progressiveJPEG = src->progressiveJPEG; dst->losslessCompress = src->losslessCompress; dst->embeddedImage = src->embeddedImage; + dst->noExit = src->noExit; } int conf_set_cmd(conf_data *conf, const conf_data *cmd) @@ -1494,6 +1499,7 @@ conf->losslessCompress = cmd->losslessCompress; if (cmd->embedExif != -1) conf->embedExif = cmd->embedExif; if (cmd->embeddedImage != -1) conf->embeddedImage = cmd->embeddedImage; + if (cmd->noExit != -1) conf->noExit = cmd->noExit; if (cmd->rotate != -1) conf->rotate = cmd->rotate; if (cmd->rotationAngle != NULLF) conf->rotationAngle = cmd->rotationAngle; if (cmd->autoCrop != -1) @@ -1880,6 +1886,7 @@ cmd->autoBlack = disabled_state; cmd->losslessCompress = -1; cmd->overwrite = -1; + cmd->noExit = -1; cmd->WindowMaximized = -1; cmd->embedExif = -1; cmd->profile[1][0].BitDepth = -1; Index: ufraw_preview.c =================================================================== RCS file: /cvsroot/ufraw/ufraw/ufraw_preview.c,v retrieving revision 1.389 diff -u -r1.389 ufraw_preview.c --- ufraw_preview.c 2 Jan 2016 16:00:21 -0000 1.389 +++ ufraw_preview.c 26 Jun 2016 12:04:00 -0000 @@ -4011,18 +4011,18 @@ // Finish this session g_object_set_data(G_OBJECT(window), "WindowResponse", (gpointer)response); - gtk_main_quit(); - } else { - // Restore setting - CFG->shrink = shrinkSave; - CFG->size = sizeSave; - data->FreezeDialog = FALSE; - gtk_widget_set_sensitive(data->Controls, TRUE); - // cases that set error status require redrawing of the preview image - if (status != UFRAW_SUCCESS) { - ufraw_invalidate_layer(data->UF, ufraw_raw_phase); - render_preview(data); - } + if (!CFG->noExit) + gtk_main_quit(); + } + // Restore setting + CFG->shrink = shrinkSave; + CFG->size = sizeSave; + data->FreezeDialog = FALSE; + gtk_widget_set_sensitive(data->Controls, TRUE); + // cases that set error status require redrawing of the preview image + if (status != UFRAW_SUCCESS || CFG->noExit) { + ufraw_invalidate_layer(data->UF, ufraw_raw_phase); + render_preview(data); } } @@ -5390,6 +5390,10 @@ button = uf_check_button_new( _("Overwrite existing files without asking"), &CFG->overwrite); gtk_box_pack_start(GTK_BOX(vBox), button, FALSE, FALSE, 0); + + button = uf_check_button_new( + _("Do not Exit after RAW development"), &CFG->noExit); + gtk_box_pack_start(GTK_BOX(vBox), button, FALSE, FALSE, 0); /* End of Save page */ } |
From: Frank v. M. <fr...@fr...> - 2016-07-10 17:11:49
|
I'm doing underwater photography with manual white balance afterwards which can get a bit unusual. The RGB channel multipliers are (for example) 4.2/1.0/5.8 and with these values temperature/green sliders clip at 2000/0.2 as it seems. The values are correctly saved in the ID file: ... <OutputPath>best</OutputPath> <WB>Manual WB</WB> <WBFineTuning>0</WBFineTuning> <Temperature>2000</Temperature> <Green>0.200</Green> <ChannelMultipliers>4.209911 1.000000 5.834866 1.000000</ChannelMultipliers> <Exposure>1.137019</Exposure> ... However, when loading the ID file (for batch processing) the white balance seems to follow the (clipped) temperature/green values instead of the RGB channel multipliers. This used to work in previous ufraw version(s). I'm using ufraw 0.22. -- Frank |
From: Pascal de B. <pmj...@pc...> - 2016-05-16 11:16:11
|
On Sun, May 15, 2016 at 8:24 PM, Alan Corey <ala...@gm...> wrote: > > As far as color management goes, Argyll works impressively well, and > > supports just about any device/chart that is worth using in the first > > place. > > Even lighter weight, I have my display .icm file that I made with my > ColorMunki while booted into Windows and I have xcalib load it from my > xinitrc file. > In my experience Argyll generally generates better profiles than the vendor software does, particular with regard to the blacks (it is significantly slower though). More importantly, if I recall correctly xcalib merely loads a profile's vcgt (VideoLUT), which is only part of the correction, then you'd still have to manually setup the ICC in each color managed application individually. Otherwise you'd be stuck with only half a correction. dispwin also sets the _ICC_PROFILE X11 atom, which most application can read if the have "Use system display profile" enabled. Which makes switching to a new updated profile much less bothersome. Keep in mind that backlights do age, so ideally you do want to generate a new profile at least yearly or half-yearly or something along those lines. Please do read my articles for more details. On a sidenote, as for printers, essentially you profile a printer+driver+driver_settings+inks+paper combination, so if you like different kinds of papers, you quickly end up doing many profiles there as well. Regards, Pascal de Bruijn |
From: Xeniya L <xus...@gm...> - 2016-05-15 21:49:05
|
you=yum - typo 2016-05-16 0:48 GMT+03:00 Xeniya L <xus...@gm...>: > I fixed problem. It was you update with enabled epel-testing. I clean > all rpms from epel-testing, and problem was solved. > > 2016-05-15 20:43 GMT+03:00 Pascal de Bruijn <pmj...@pc...>: >> On Sun, May 15, 2016 at 12:57 AM, Xeniya L <xus...@gm...> wrote: >>> >>> Hi all! >>> >>> After I updated my desktop centos system, I get segfaulting error. >>> I tried to use strace, but it just freezing, and don't segfault ( I >>> want to fine last libs which are required and loaded for ufraw binary >>> file). >> >> >> When does it segfault? When loading a RAW file? If so, from which camera? >> >> Running ufraw through gdb might be a good idea. Should be something along >> these lines: >> >> gdb ufraw >> r >> (do whatever you need to do to crash it) >> bt >> >> paste back to results. >> >> Regards, >> Pascal de Bruijn >> >> >> ------------------------------------------------------------------------------ >> Mobile security can be enabling, not merely restricting. Employees who >> bring their own devices (BYOD) to work are irked by the imposition of MDM >> restrictions. Mobile Device Manager Plus allows you to control only the >> apps on BYO-devices by containerizing them, leaving personal data untouched! >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j >> _______________________________________________ >> ufraw-devel mailing list >> ufr...@li... >> https://lists.sourceforge.net/lists/listinfo/ufraw-devel >> |
From: Xeniya L <xus...@gm...> - 2016-05-15 21:48:23
|
I fixed problem. It was you update with enabled epel-testing. I clean all rpms from epel-testing, and problem was solved. 2016-05-15 20:43 GMT+03:00 Pascal de Bruijn <pmj...@pc...>: > On Sun, May 15, 2016 at 12:57 AM, Xeniya L <xus...@gm...> wrote: >> >> Hi all! >> >> After I updated my desktop centos system, I get segfaulting error. >> I tried to use strace, but it just freezing, and don't segfault ( I >> want to fine last libs which are required and loaded for ufraw binary >> file). > > > When does it segfault? When loading a RAW file? If so, from which camera? > > Running ufraw through gdb might be a good idea. Should be something along > these lines: > > gdb ufraw > r > (do whatever you need to do to crash it) > bt > > paste back to results. > > Regards, > Pascal de Bruijn > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > |
From: Alan C. <ala...@gm...> - 2016-05-15 18:24:25
|
> As far as color management goes, Argyll works impressively well, and > supports just about any device/chart that is worth using in the first > place. Even lighter weight, I have my display .icm file that I made with my ColorMunki while booted into Windows and I have xcalib load it from my xinitrc file. My printer's on a Windows box and the printer driver loads the .icm file for that so it's independent of what software I use. Something under Windows loads the display .icm file there, I forget what. I don't regret buying the ColorMunki but in retrospect renting one for a week would have been adequate. At least until something dies and I need to calibrate a replacement. But that includes toner cartridges for my laser printer. So software couldn't do the trick by itself, I needed to bootstrap calibrated hardware. I forget what this ColorMunki is called but it does displays and printers. And comes with a colorchecker/Macbeth card which can work with scanners and cameras. |
From: Pascal de B. <pmj...@pc...> - 2016-05-15 18:13:37
|
On Sun, May 15, 2016 at 12:57 AM, Xeniya L <xus...@gm...> wrote: > Hi all! > > After I updated my desktop centos system, I get segfaulting error. > I tried to use strace, but it just freezing, and don't segfault ( I > want to fine last libs which are required and loaded for ufraw binary > file). > When does it segfault? When loading a RAW file? If so, from which camera? Running ufraw through gdb might be a good idea. Should be something along these lines: gdb ufraw r (do whatever you need to do to crash it) bt paste back to results. Regards, Pascal de Bruijn |
From: Pascal de B. <pmj...@pc...> - 2016-05-15 17:59:17
|
On Thu, Oct 1, 2015 at 12:07 AM, Greg Troxel <gd...@ir...> wrote: > > Alan Corey <ala...@gm...> 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, still > > program for fun, mostly in C. I have a Color Munki and I've read > > quite a bit about having everything calibrated. > > welcome to ufraw > Sorry for jumping in late... But... As far as color management goes, Argyll works impressively well, and supports just about any device/chart that is worth using in the first place. https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ https://encrypted.pcode.nl/blog/2012/01/29/color-management-on-linux/ https://encrypted.pcode.nl/blog/2010/06/28/darktable-camera-color-profiling/ (should work for ufraw just fine too) And a little experimental side project of mine: https://github.com/pmjdebruijn/colormatch Regards, Pascal de Bruijn |
From: Alan C. <ala...@gm...> - 2016-05-14 23:36:42
|
Well, it sure takes a long time to turn the digest over, I hadn't thought about this in months. A consideration I ran into is that RAW files aren't just RGB, they're more like RGGB because the sensors have twice as many green pixels as reb and blue. I don't remember why I stopped working on it though. I was using code from dcraw to get the raw data. I later found an email from Dave Coffin he sent 2/25/2016 in my spam folder, I didn't find it until 3/24/2016. He said: "dcraw -E -4" gets you the raw unscaled pixels; this is mentioned in the manpage under the "-I" option. This does not pass through any metadata, such as the filter pattern, that you would need to correctly decode the image. Dave Coffin 2/25/2016 Filter pattern here refers to the RGGB thing I think. Maybe it was discovering that my monitor has much more backlight at the bottom than elsewhere, messing up photos taken of the screen. No idea really. |