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: Xeniya L <xus...@gm...> - 2016-05-14 22:57:53
|
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). I try nux rpm package, also I try rebuild last fedora rpm package - ufraw-0.21-3. Same error. |
From: Alexandre P. <ale...@gm...> - 2015-12-25 11:41:54
|
On Fri, Dec 25, 2015 at 3:14 AM, Greg Troxel wrote: > > 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? https://git.gnome.org/browse/gtkimageview That is really all there is now. Releases weren't moved to GNOME's FTP. Alex |
From: Greg T. <gd...@ir...> - 2015-12-25 00:14:34
|
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? |
From: Greg T. <gd...@ir...> - 2015-10-02 22:11:21
|
Niels Kristian Bech Jensen <nkb...@ho...> 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 JPEGs which means that pixels are not just pixels. For this and similar reasons, I'd advise using a photo where most of it is a grey card, or a color checker, and only worrying about color/luminance in the patch areas. Even just figuring out luminance for 18% grey would be a big contribution. |
From: Niels K. B. J. <nkb...@ho...> - 2015-10-01 23:30:41
|
> 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 JPEGs which means that pixels are not just pixels. Regards, Niels Kristian |
From: Alan C. <ala...@gm...> - 2015-10-01 18:31:06
|
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. On 10/1/15, Greg Troxel <gd...@ir...> wrote: > > Also, note that in Nikon at least, you can shoot RAW+JPG. SO you can > just compared raw->jpg with camera jpg, just bits. > -- Credit is the root of all evil. - AB1JX |
From: Greg T. <gd...@ir...> - 2015-10-01 18:09:03
|
Also, note that in Nikon at least, you can shoot RAW+JPG. SO you can just compared raw->jpg with camera jpg, just bits. |
From: Alan C. <ala...@gm...> - 2015-10-01 14:26:17
|
Actually I might just work on the program. These are 2 different versions of the same image and comparing those is more important than having the image perfect. They were both the same exposure and plotting the values in one vs the other could be useful. They both have exactly the same flaws. From the standpoint of comparing a red (or green, or blue) of x value against the same swatch in the other it should still work. On 10/1/15, Alan Corey <ala...@gm...> wrote: > Last in, first out. I have an HP 2025dn color laser printer which, > once I replaced the demo toner cartridges printed purple flowers as > blue. So I bought the Color Munki and calibrated the printer and my > monitors. The Color Munki software doesn't run under Unix, it's > Windows/Mac only, but most of my computers have multiple operating > systems and once I had the monitor icm files I can load them at boot > with xcalib. The printer's attached to a Windows machine and does > reasonably well except on some browns. > > I carefully did some photographs of my color grid on my monitor screen > with my Nikon D5200, intending to compare the raw to jpeg that way. > The first annoyance was having to defocus slightly to avoid moire. > > The show stopper for now is the backlighting in my monitor, a Dell > S2409 which I've been happy with for years. Notice the difference in > the gray area at left between the top and bottom of the images. > There's ccfl backlighting at the bottom, looks like I should invest in > another monitor. > > The second image is the raw file converted with dcraw -4 -T to a tiff, > then Gimp to a jpeg. The camera's set to save jpeg and raw from each > image. Metering is just averaging. > > I think I could write a program to sample and average the color > swatches, stopping at the white grid at the edge of each. I got up > looking forward to that, then hit the backlighting problem. > > On 10/1/15, Greg Troxel <gd...@ir...> wrote: >> >> Alan Corey <ala...@gm...> 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 != wrong, in some ways. There is scene >> luminance, which raw should arguably be trying to record, and then there >> is developed digital file luminance, and then there is print luminance. >> Photography has a long history of transforming scene luminance (via >> negative density) to print luminance in a pleasing transformation vs a >> quantitatively accurate one. The Ansel Adams writings about the zone >> system and -/+ development is interesting. >> >> However, all that said, when you have a reasonable illuminant, and spot >> meter on a grey card, then you expect to get something that's mid-range >> in the camera-produced jpeg and also in the jpeg/tiff/whatever produced >> by raw conversion with +0 exposure compensation. And also the white >> card should be two stops higher (90 vs 18). If I had more Copious Spare >> Time, I'd focus on just that first. In my experience that's most of >> the issue. >> >>> This is something I was working on for printer calibration before I >>> gave up and bought a Color Munki. I'm not sure I finished a parser >>> for reading back the printed out versions from a scan. Linearity and >>> the range of actual colors would be an issue. I think I was looking >>> at the mixing that happens here because printers use cmyk and I was >>> trying to look at rgb, so whenever I'd ramp up one color others would >>> go along with it. Some of that might have been to create a value >>> change. >> >> There are multiple open source projects for calibration/profiling. >> lprof seems inactive but worth looking at, and Argyll. lcms2 can do >> cmyk/rgb converesions, I think. I have also seen IT8 targets >> available, plus color checkers are not that expensive. >> >> >> > > > -- > Credit is the root of all evil. - AB1JX > -- Credit is the root of all evil. - AB1JX |
From: Alan C. <ala...@gm...> - 2015-10-01 13:54:39
|
Last in, first out. I have an HP 2025dn color laser printer which, once I replaced the demo toner cartridges printed purple flowers as blue. So I bought the Color Munki and calibrated the printer and my monitors. The Color Munki software doesn't run under Unix, it's Windows/Mac only, but most of my computers have multiple operating systems and once I had the monitor icm files I can load them at boot with xcalib. The printer's attached to a Windows machine and does reasonably well except on some browns. I carefully did some photographs of my color grid on my monitor screen with my Nikon D5200, intending to compare the raw to jpeg that way. The first annoyance was having to defocus slightly to avoid moire. The show stopper for now is the backlighting in my monitor, a Dell S2409 which I've been happy with for years. Notice the difference in the gray area at left between the top and bottom of the images. There's ccfl backlighting at the bottom, looks like I should invest in another monitor. The second image is the raw file converted with dcraw -4 -T to a tiff, then Gimp to a jpeg. The camera's set to save jpeg and raw from each image. Metering is just averaging. I think I could write a program to sample and average the color swatches, stopping at the white grid at the edge of each. I got up looking forward to that, then hit the backlighting problem. On 10/1/15, Greg Troxel <gd...@ir...> wrote: > > Alan Corey <ala...@gm...> 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 != wrong, in some ways. There is scene > luminance, which raw should arguably be trying to record, and then there > is developed digital file luminance, and then there is print luminance. > Photography has a long history of transforming scene luminance (via > negative density) to print luminance in a pleasing transformation vs a > quantitatively accurate one. The Ansel Adams writings about the zone > system and -/+ development is interesting. > > However, all that said, when you have a reasonable illuminant, and spot > meter on a grey card, then you expect to get something that's mid-range > in the camera-produced jpeg and also in the jpeg/tiff/whatever produced > by raw conversion with +0 exposure compensation. And also the white > card should be two stops higher (90 vs 18). If I had more Copious Spare > Time, I'd focus on just that first. In my experience that's most of > the issue. > >> This is something I was working on for printer calibration before I >> gave up and bought a Color Munki. I'm not sure I finished a parser >> for reading back the printed out versions from a scan. Linearity and >> the range of actual colors would be an issue. I think I was looking >> at the mixing that happens here because printers use cmyk and I was >> trying to look at rgb, so whenever I'd ramp up one color others would >> go along with it. Some of that might have been to create a value >> change. > > There are multiple open source projects for calibration/profiling. > lprof seems inactive but worth looking at, and Argyll. lcms2 can do > cmyk/rgb converesions, I think. I have also seen IT8 targets > available, plus color checkers are not that expensive. > > > -- Credit is the root of all evil. - AB1JX |
From: Greg T. <gd...@ir...> - 2015-10-01 12:52:40
|
Alan Corey <ala...@gm...> 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 != wrong, in some ways. There is scene luminance, which raw should arguably be trying to record, and then there is developed digital file luminance, and then there is print luminance. Photography has a long history of transforming scene luminance (via negative density) to print luminance in a pleasing transformation vs a quantitatively accurate one. The Ansel Adams writings about the zone system and -/+ development is interesting. However, all that said, when you have a reasonable illuminant, and spot meter on a grey card, then you expect to get something that's mid-range in the camera-produced jpeg and also in the jpeg/tiff/whatever produced by raw conversion with +0 exposure compensation. And also the white card should be two stops higher (90 vs 18). If I had more Copious Spare Time, I'd focus on just that first. In my experience that's most of the issue. > This is something I was working on for printer calibration before I > gave up and bought a Color Munki. I'm not sure I finished a parser > for reading back the printed out versions from a scan. Linearity and > the range of actual colors would be an issue. I think I was looking > at the mixing that happens here because printers use cmyk and I was > trying to look at rgb, so whenever I'd ramp up one color others would > go along with it. Some of that might have been to create a value > change. There are multiple open source projects for calibration/profiling. lprof seems inactive but worth looking at, and Argyll. lcms2 can do cmyk/rgb converesions, I think. I have also seen IT8 targets available, plus color checkers are not that expensive. |
From: Alan C. <ala...@gm...> - 2015-10-01 00:57:18
|
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. This is something I was working on for printer calibration before I gave up and bought a Color Munki. I'm not sure I finished a parser for reading back the printed out versions from a scan. Linearity and the range of actual colors would be an issue. I think I was looking at the mixing that happens here because printers use cmyk and I was trying to look at rgb, so whenever I'd ramp up one color others would go along with it. Some of that might have been to create a value change. I'm not sure my parser works, I may have been using the eyedropper in gimp and entering the numbers manually. The plot is from Gnuplot. It was partly seeing jpeg artifacts in my photos of the printed grid that convinced me I wanted to do RAW. The grid was made by writing into an array in memory then writing that array out as an image. The font was stolen from giflib or libgif. On 9/30/15, Greg Troxel <gd...@ir...> wrote: > > Alan Corey <ala...@gm...> 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 >> recreation will go back to making custom hyperfocal tables. > > It would be a real contribution to understand the calibration from raw > to JPEG so that we could more or less reproduce the camera > transformation. I'm not saying that's right, but it would be a nice > reference point. I find that with nikon bodies, I need significant + > exposure compenation in ufraw to match the jpegs. > -- Credit is the root of all evil. - AB1JX |
From: Greg T. <gd...@ir...> - 2015-10-01 00:08:53
|
Alan Corey <ala...@gm...> 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 > recreation will go back to making custom hyperfocal tables. It would be a real contribution to understand the calibration from raw to JPEG so that we could more or less reproduce the camera transformation. I'm not saying that's right, but it would be a nice reference point. I find that with nikon bodies, I need significant + exposure compenation in ufraw to match the jpegs. |
From: Alan C. <ala...@gm...> - 2015-10-01 00:04:30
|
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 recreation will go back to making custom hyperfocal tables. On 9/30/15, 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 -- Credit is the root of all evil. - AB1JX |
From: Greg T. <gd...@ir...> - 2015-09-30 22:07:18
|
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 > The current Ufraw homepage at http://ufraw.sourceforge.net/ says it's > going to get into more detail later about color matrices but as far as > I can tell never does. > > The only photography text I ever read cover to cover is Mastering > Photographic Composition, Creativity and Personal Style by Alain > Briot. He's a big fan of using gray cards, Macbeth color charts, I > have great hope for white plastic lens caps but I don't have one yet. > The idea being that white balance needs to be more dynamic than > manufacturer presets like cloudy and incandescent. When I use the > cloudy setting the pictures are too yellow, then again there are dark > clouds and light clouds. Indeed. You might want to read Color Science by Wysecki and Stiles. > I wrote a program that takes a JPEG shot of a gray card and outputs an > averaged hue and RGB values. Because it might not be full frame or > there might be a thumb holding the card I do: Take an overall mean > hue, calculate a standard deviation, then a second mean hue of pixels > within 1 standard deviation of the mean, then mean RGB values for > those pixels. It's just a command line thing, the only dependency is > the common JPEG library. To deal with this, what I do is to use only raw, and to take an image of a grey card (or the white card on the back). As Udi said, JPEG has the camera's WB worked into it, and what you really want is the transform from raw to correct JPEG. > What I'd like to do is output numbers that can plug into Ufraw's > channel multipliers and green and temperature settings. Those 5 > numbers seem linked in ways I don't understand yet. I don't like > using the eyedropper to sample a neutral area of the real image > because it assumes there is one. There also doesn't seem to be a > provision for using a full-frame shot of a gray card and applying the > numbers to a different image. Then I use the selector on the grey/white section of the grey card shot, and use the 'neutral' button to adjust color balance to make the *converted* pixel values equal. I then save this. Then, when I open a real picture, it inherits the WB setting from the gray card adjustment, and things work out. In theory, the relationship between channel multipliers and color temperature/green is straightforward math, but really it's based on the multipliers the camera reports when setting particular temperatures and then interpolating. Partly this is because the gain calibration has to be worked in. But regardless, if you shoot a white card in the same light, and balance it, you should get quite close. |
From: Udi F. <udi...@us...> - 2015-09-30 06:43:12
|
Hi, There is an option to select an area in UFRaw to be used for white balance. There is no command line option to apply your own RGB values from the command line. The way to do it would be to create a UFRaw ID file with the relevant numbers. But, the RGB values you are getting from the JPG image are not directly relevant for applying to the raw image. The JPG image already had some white balance correction applied to it. There is also a color matrix that mixes the raw channels to get the RGB channels, a gamma curve and other corrections. These make it very tricky to translate the JPG values you are getting to raw channel multipliers. Udi On Wed, Sep 30, 2015 at 6:49 AM, Alan Corey <ala...@gm...> wrote: > 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. > > The current Ufraw homepage at http://ufraw.sourceforge.net/ says it's > going to get into more detail later about color matrices but as far as > I can tell never does. > > The only photography text I ever read cover to cover is Mastering > Photographic Composition, Creativity and Personal Style by Alain > Briot. He's a big fan of using gray cards, Macbeth color charts, I > have great hope for white plastic lens caps but I don't have one yet. > The idea being that white balance needs to be more dynamic than > manufacturer presets like cloudy and incandescent. When I use the > cloudy setting the pictures are too yellow, then again there are dark > clouds and light clouds. > > I wrote a program that takes a JPEG shot of a gray card and outputs an > averaged hue and RGB values. Because it might not be full frame or > there might be a thumb holding the card I do: Take an overall mean > hue, calculate a standard deviation, then a second mean hue of pixels > within 1 standard deviation of the mean, then mean RGB values for > those pixels. It's just a command line thing, the only dependency is > the common JPEG library. > > What I'd like to do is output numbers that can plug into Ufraw's > channel multipliers and green and temperature settings. Those 5 > numbers seem linked in ways I don't understand yet. I don't like > using the eyedropper to sample a neutral area of the real image > because it assumes there is one. There also doesn't seem to be a > provision for using a full-frame shot of a gray card and applying the > numbers to a different image. > > -- > Credit is the root of all evil. - AB1JX > > > ------------------------------------------------------------------------------ > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > |
From: Alan C. <ala...@gm...> - 2015-09-30 04:49:30
|
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. The current Ufraw homepage at http://ufraw.sourceforge.net/ says it's going to get into more detail later about color matrices but as far as I can tell never does. The only photography text I ever read cover to cover is Mastering Photographic Composition, Creativity and Personal Style by Alain Briot. He's a big fan of using gray cards, Macbeth color charts, I have great hope for white plastic lens caps but I don't have one yet. The idea being that white balance needs to be more dynamic than manufacturer presets like cloudy and incandescent. When I use the cloudy setting the pictures are too yellow, then again there are dark clouds and light clouds. I wrote a program that takes a JPEG shot of a gray card and outputs an averaged hue and RGB values. Because it might not be full frame or there might be a thumb holding the card I do: Take an overall mean hue, calculate a standard deviation, then a second mean hue of pixels within 1 standard deviation of the mean, then mean RGB values for those pixels. It's just a command line thing, the only dependency is the common JPEG library. What I'd like to do is output numbers that can plug into Ufraw's channel multipliers and green and temperature settings. Those 5 numbers seem linked in ways I don't understand yet. I don't like using the eyedropper to sample a neutral area of the real image because it assumes there is one. There also doesn't seem to be a provision for using a full-frame shot of a gray card and applying the numbers to a different image. -- Credit is the root of all evil. - AB1JX |
From: Wolfgang G. <Wol...@we...> - 2015-08-01 06:21:48
|
Niels Kristian Bech Jensen wrote: > The cvs servers at sourceforge.net have been down since July 16th due > to a storage fault. They came online again late last night. good news! > I have > just updated wb_presets.c with support for three new cameras: SONY > DSC-RX10, > NIKON 1 J5 (from Darktable) cvs update, install, check ... OK! kind regards Wolfgang fyi: not detected in Darktable because 'NIKON' should be 'Nikon' issued mail + pull request to correct my first nonworking/nontested wb input. yeah..i know: always test, don't rely on scripts working 2 years ago #-P ufraw matches case insensitive. (i tried both) diff ufraw/wb_presets.c darktable/src/external/wb_presets.c|wc 12263 156351 879820 ufraw/wb_extract.pl uses exiftool -Model exiftool -Model 20150726-01170252-NIKON_1_J5.nef Camera Model Name : NIKON 1 J5 comment in wb_preset.c: * Column 2 - "model" (use the "make" and "model" as provided by DCRaw). dcraw -i -v 20150726-01170252-NIKON_1_J5.nef Filename: 20150726-01170252-NIKON_1_J5.nef Timestamp: Sun Jul 26 01:17:02 2015 Camera: Nikon 1 J5 ISO speed: 6400 Shutter: 1/2.0 sec Aperture: f/3.5 Focal length: 10.0 mm Embedded ICC profile: no Number of raw images: 1 Thumb size: 5568 x 3712 Full size: 5584 x 3726 Image size: 5584 x 3724 Output size: 5584 x 3724 Raw colors: 3 Filter pattern: RG/GB Daylight multipliers: 2.024444 0.931436 1.259885 Camera multipliers: 2.378906 1.000000 1.324219 0.000000 > and OLYMPUS TG-4 (from > Darktable). Regards, Niels Kristian > Date: Fri, 31 Jul 2015 19:41:04 +0200 > From: Wol...@we... > To: ufr...@li... > Subject: [UFRaw-Devel] cvs login aborted, wb_presets NIKON 1 J5 > > Hello, > > the cvs server seems nonfunctional: > cvs update in existing directory fails (want patch against actual > version) > fresh: > cvs -d:pserver:ano...@uf...:/cvsroot/ufraw > login Logging in > to :pserver:ano...@uf...:2401/cvsroot/ufraw > CVS password: cvs [login aborted]: reading from server: Connection > reset by peer > > > > > > wb_presets: may be you find this helpful: > > > { "NIKON", "1 J5", Incandescent, 0, { 1.546875, 1, 2.171875, 0 } }, > { "NIKON", "1 J5", CoolWhiteFluorescent, 0, { 2.15625, 1, 1.94921875, > 0 } }, { "NIKON", "1 J5", DirectSunlight, 0, { 2.31640625, 1, > 1.37890625, 0 } }, { "NIKON", "1 J5", Flash, 0, { 2.62109375, 1, > 1.16796875, 0 } }, { "NIKON", "1 J5", Cloudy, 0, { 2.4609375, 1, > 1.2578125, 0 } }, { "NIKON", "1 J5", Shade, 0, { 2.78515625, 1, > 1.125, 0 } }, > > > > what happened with the cooperation darktable/ufraw when it comes to > wb presets? > > > kind regards > Wolfgang > > ------------------------------------------------------------------------------ > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > |
From: Niels K. B. J. <nkb...@ho...> - 2015-08-01 03:09:37
|
The cvs servers at sourceforge.net have been down since July 16th due to a storage fault. They came online again late last night. I have just updated wb_presets.c with support for three new cameras: SONY DSC-RX10, NIKON 1 J5 (from Darktable) and OLYMPUS TG-4 (from Darktable). Regards, Niels Kristian Date: Fri, 31 Jul 2015 19:41:04 +0200 From: Wol...@we... To: ufr...@li... Subject: [UFRaw-Devel] cvs login aborted, wb_presets NIKON 1 J5 Hello, the cvs server seems nonfunctional: cvs update in existing directory fails (want patch against actual version) fresh: cvs -d:pserver:ano...@uf...:/cvsroot/ufraw login Logging in to :pserver:ano...@uf...:2401/cvsroot/ufraw CVS password: cvs [login aborted]: reading from server: Connection reset by peer wb_presets: may be you find this helpful: { "NIKON", "1 J5", Incandescent, 0, { 1.546875, 1, 2.171875, 0 } }, { "NIKON", "1 J5", CoolWhiteFluorescent, 0, { 2.15625, 1, 1.94921875, 0 } }, { "NIKON", "1 J5", DirectSunlight, 0, { 2.31640625, 1, 1.37890625, 0 } }, { "NIKON", "1 J5", Flash, 0, { 2.62109375, 1, 1.16796875, 0 } }, { "NIKON", "1 J5", Cloudy, 0, { 2.4609375, 1, 1.2578125, 0 } }, { "NIKON", "1 J5", Shade, 0, { 2.78515625, 1, 1.125, 0 } }, what happened with the cooperation darktable/ufraw when it comes to wb presets? kind regards Wolfgang ------------------------------------------------------------------------------ _______________________________________________ ufraw-devel mailing list ufr...@li... https://lists.sourceforge.net/lists/listinfo/ufraw-devel |
From: Wolfgang G. <Wol...@we...> - 2015-07-31 17:41:24
|
Hello, the cvs server seems nonfunctional: cvs update in existing directory fails (want patch against actual version) fresh: cvs -d:pserver:ano...@uf...:/cvsroot/ufraw login Logging in to :pserver:ano...@uf...:2401/cvsroot/ufraw CVS password: cvs [login aborted]: reading from server: Connection reset by peer wb_presets: may be you find this helpful: { "NIKON", "1 J5", Incandescent, 0, { 1.546875, 1, 2.171875, 0 } }, { "NIKON", "1 J5", CoolWhiteFluorescent, 0, { 2.15625, 1, 1.94921875, 0 } }, { "NIKON", "1 J5", DirectSunlight, 0, { 2.31640625, 1, 1.37890625, 0 } }, { "NIKON", "1 J5", Flash, 0, { 2.62109375, 1, 1.16796875, 0 } }, { "NIKON", "1 J5", Cloudy, 0, { 2.4609375, 1, 1.2578125, 0 } }, { "NIKON", "1 J5", Shade, 0, { 2.78515625, 1, 1.125, 0 } }, what happened with the cooperation darktable/ufraw when it comes to wb presets? kind regards Wolfgang |
From: Niels K. B. J. <nkb...@ho...> - 2015-06-16 06:20:11
|
Excellent. I will make a last round of tests Tonight when I get home from work. Regards, Niels Kristian Date: Mon, 15 Jun 2015 23:56:56 -0500 From: udi...@us... To: ufr...@li... Subject: Re: [UFRaw-Devel] release? Sorry for the late reply. I could make a release tomorrow. It might be too late for Greg, but there are enough changes to warrant a release. Udi On Sun, Jun 14, 2015 at 6:09 AM, Niels Kristian Bech Jensen <nkb...@ho...> wrote: I have not heard anything from Udi so I will not make the release Today. Regards, Niels Kristian ------------------------------------------------------------------------------ _______________________________________________ ufraw-devel mailing list ufr...@li... https://lists.sourceforge.net/lists/listinfo/ufraw-devel ------------------------------------------------------------------------------ _______________________________________________ ufraw-devel mailing list ufr...@li... https://lists.sourceforge.net/lists/listinfo/ufraw-devel |
From: Udi F. <udi...@us...> - 2015-06-16 04:57:03
|
Sorry for the late reply. I could make a release tomorrow. It might be too late for Greg, but there are enough changes to warrant a release. Udi On Sun, Jun 14, 2015 at 6:09 AM, Niels Kristian Bech Jensen < nkb...@ho...> wrote: > I have not heard anything from Udi so I will not make the release Today. > > Regards, > Niels Kristian > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > ufraw-devel mailing list > ufr...@li... > https://lists.sourceforge.net/lists/listinfo/ufraw-devel > > |
From: Niels K. B. J. <nkb...@ho...> - 2015-06-14 11:09:57
|
I have not heard anything from Udi so I will not make the release Today. Regards, Niels Kristian |
From: Niels K. B. J. <nkb...@ho...> - 2015-06-07 12:27:25
|
> 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. I think I can make a release next Sunday (June 14th). @Udi: Could you send a message to the translators if you agree? Regards, Niels Kristian |
From: Greg T. <gd...@ir...> - 2015-06-07 12:03:47
|
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.) |
From: Pascal de B. <pmj...@pc...> - 2015-05-04 16:39:21
|
On Mon, May 4, 2015 at 4:57 PM, Udi Fuchs <udi...@us...> wrote: > > Currently when loading a profile into UFRaw, UFRaw displays it's base >> filename, which may or may not be helpful. >> >> ICC Profiles have a description field, which can be read and used. >> > > The problem is that some profiles have a useless description. This makes > it impossible to know which profile you are applying. > Technically speaking that's the profile's problem, not UFRaw's :) This ICC description field exists for this particular reason. By using filenames, I can be sure that I'm getting a unique name. > Same profile filename in two different directories leaves you with the same problem. I guess damned if you do, damned if you don't :) Regards, Pascal de Bruijn |