Am Montag, 10. Juni 2013, 17:50:44 schrieb Madko:
[...]
> therefor it's still distributed (within the SRPM). Fedora could decide to
> remove darktable from their repos for that :(
They are free to remove darktable if they don't like it, no one will try to
stop them.
Some people really have too
Hi Roumano,
thanks for giving my code changes a try!
I should mention that the isolated profiling data from OpenCL not always
give a good indication. Some devices/drivers for example do not account
for the full host<->device transfer timings. It's better to rely on the
total time spent in the
> "Madko" == Madko writes:
Madko> The problem about squish is that some (at least Fedora/RH)
Madko> thinks that distributing patented sources is as harmful as
Madko> distributing the compiled version... Debian's point of view
Madko> is that source code is like free speech (at
The problem about squish is that some (at least Fedora/RH) thinks that
distributing patented sources is as harmful as distributing the compiled
version... Debian's point of view is that source code is like free speech
(at least in the US), and it's just a description of the invention, not the
inven
> "Tobias" == Tobias Ellinghaus writes:
Tobias> Most arguments in that bug report are nonsense. It's not a
Tobias> matter of user experience, it's just that we added a new
Tobias> feature to libraw that we need and that doesn't exist
Tobias> upstream. And the latest ups
Am Montag, 10. Juni 2013, 14:53:42 schrieb Frédéric Granier:
> I use gcc 4.8.1 from archlinux official repositories. I've tried to
> compile darktable with the package provided in AUR and then by
> following the instructions from darktable website. In both case I have
> the same error (even with th
Am Montag, 10. Juni 2013, 14:16:28 schrieb tog...@users.sourceforge.net:
> > "Simon" == Simon writes:
> Simon> The reasons for not using 0.15 are summarized here:
> Simon> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
>
> Yes but the reasons could be valid for any software
those high iso graphs look fairly atypical, my guess is it's processed in
camera.
-jo
On Mon, Jun 10, 2013 at 3:33 PM, TCJ wrote:
> Hi!
>
> I have made five attempts at creating a noise profile for the Panasonic
> GF2.
>
> However, I have been unable to create a good match at higher ISO.
>
> T
Hi!
I have made five attempts at creating a noise profile for the Panasonic GF2.
However, I have been unable to create a good match at higher ISO.
The profiles and a comparison chart of their de-noising effects can be
downloaded from:
https://www.dropbox.com/sh/qs0pj5dr2scmkuy/p2wYNcVRE5
I'm
perfect :)
2013/6/10 johannes hanika
> oh, i only pushed to master, now in darktable-1.2.x, too.
>
> -jo
>
>
> On Mon, Jun 10, 2013 at 2:45 PM, Madko wrote:
>
>> Thank you Johannes for this clear explaination about libraw. So the best
>> solution would be to use rawstudio code, any "plan" to d
oh, i only pushed to master, now in darktable-1.2.x, too.
-jo
On Mon, Jun 10, 2013 at 2:45 PM, Madko wrote:
> Thank you Johannes for this clear explaination about libraw. So the best
> solution would be to use rawstudio code, any "plan" to do that in future
> releases?
>
> Sorry to come back a
I use gcc 4.8.1 from archlinux official repositories. I've tried to
compile darktable with the package provided in AUR and then by
following the instructions from darktable website. In both case I have
the same error (even with the -w flag).
>Am Montag, 10. Juni 2013, 13:47:48 schrieb Fr?d?ric Gr
Thank you Johannes for this clear explaination about libraw. So the best
solution would be to use rawstudio code, any "plan" to do that in future
releases?
Sorry to come back about squish, I try the -DUSE_SQUISH=OFF with no success:
CMake Warning:
Manually-specified variables were not used by t
1) white balance for > 16 bit dng: alex doesn't want to support that format
at all, in fact our copy of libraw only doesn't crash on it because these
files are opened with rawspeed. so he has a point i guess.
the clean way to solve this would be on our end not to use libraw to read
camera-wb from
Do you know why they removed those functionnalities?
2013/6/10 johannes hanika
> no, not possible. we need to revert a couple of commits from upsteam to
> get back functionality that has been removed over the years.
>
> -jo
>
>
> On Mon, Jun 10, 2013 at 1:38 PM, Madko wrote:
>
>> Is it possibl
no, not possible. we need to revert a couple of commits from upsteam to get
back functionality that has been removed over the years.
-jo
On Mon, Jun 10, 2013 at 1:38 PM, Madko wrote:
> Is it possible to build darktable against LibRaw from the system, not
> against the one provided in src/exter
> "Simon" == Simon writes:
Simon> The reasons for not using 0.15 are summarized here:
Simon> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
Yes but the reasons could be valid for any software that is needing
external libraries and that makes it awkward for the package maint
Am Montag, 10. Juni 2013, 13:47:48 schrieb Frédéric Granier:
> Hello everyone !
Hello,
> Since a few days i can't anymore compile darktable from the git
> version. I have an error in the demosaic module since the code from
> raw therapee has been merged (commit
> 70d056abc010707cd0803cc987cef2bc4
Hello everyone !
Since a few days i can't anymore compile darktable from the git
version. I have an error in the demosaic module since the code from
raw therapee has been merged (commit
70d056abc010707cd0803cc987cef2bc44b3e1f4 by pmjdebruijn).
Here is the log of the error:
[ 80%] Building C obje
The reasons for not using 0.15 are summarized here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
On 06/10/2013 01:38 PM, Madko wrote:
> Is it possible to build darktable against LibRaw from the system, not
> against the one provided in src/external?
>
>
> 2013/6/10 Jose Carlos Garcia So
Am Montag, 10. Juni 2013, 11:18:56 schrieb johannes hanika:
[...]
> >- LibRaw is suffering from a security issue
>
> not the version we use, ours is too old.
There was a fix [0] packported from the 0.15 branch to the 0.14 branch of
libraw. I applied it to our copy.
Tobias
[...]
[0]
https:/
Is it possible to build darktable against LibRaw from the system, not
against the one provided in src/external?
2013/6/10 Jose Carlos Garcia Sogo
> On Mon, Jun 10, 2013 at 11:55 AM, Madko wrote:
> > Thanks Johannes
> >
> > about squish and its patented algorithm (DXT), is it right to distribut
On Mon, Jun 10, 2013 at 11:55 AM, Madko wrote:
> Thanks Johannes
>
> about squish and its patented algorithm (DXT), is it right to distribute it
> in your sources tarballs?
Yes, it is: http://www.debian.org/reports/patent-faq
--
Hi Ulrich,
Test on a ATI Tahiti XT (7870 XT 2Go) with a picture 5196 * 3462 pixel
size (18Mbit)
For me, i can't see any difference on the picture. (but file size is 2
Ko diff) (every time a exporting a file i never have the exactly same
size of the file)
For performance,
Yes it's better for me
Thanks Johannes
about squish and its patented algorithm (DXT), is it right to distribute it
in your sources tarballs?
2013/6/10 johannes hanika
> git checkout master
> cmake -DUSE_SQUISH=off
>
> j.
>
>
> On Mon, Jun 10, 2013 at 11:18 AM, johannes hanika wrote:
>
>>
>> >- squish is unsuitable f
Hi John,
We at darktable (http://www.darktable.org) are using osm-gps-map to
have a map view and geotag images. While the web page of the project
lists this library as GPLv3, the header in files lists them as GPLv2,
without the option to use "any later version". That makes the libray
GPLv2 only, a
git checkout master
cmake -DUSE_SQUISH=off
j.
On Mon, Jun 10, 2013 at 11:18 AM, johannes hanika wrote:
>
> >- squish is unsuitable for Fedora, snce it implement s3tc, a patented
> algorithm ( found by Nicolas Chauvet )
>
> it's optional and switched off by default. i can make it a compile time
>- squish is unsuitable for Fedora, snce it implement s3tc, a patented
algorithm ( found by Nicolas Chauvet )
it's optional and switched off by default. i can make it a compile time
switch if that solves the problem?
>- LibRaw is suffering from a security issue
not the version we use, ours is to
Hi,
please can someone look at this bug report
https://bugzilla.redhat.com/show_bug.cgi?id=972604 and tell me if you agree
with the reporter (specially the license problem).
Thanks
--
Edouard Bourguignon
--
How ServiceN
29 matches
Mail list logo