2013/6/5 Togan Muftuoglu :
> On 06/05/2013 10:56 PM, jeremy rosen wrote:
>> IIUC what hanatos said, it's not just a question of adapting. upstream has
>> removed features that we need.
>>
>> so either we drop libraw entirely or we fork it entirely, but we can't use
>> upstream because upstream has
On Thu, Jun 6, 2013 at 9:14 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:56 PM, jeremy rosen wrote:
> > IIUC what hanatos said, it's not just a question of adapting. upstream
> has
> > removed features that we need.
> >
> > so either we drop libraw entirely or we f
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
i'll look into adding a compile switch to build without it, if that
resolves your packaging concerns. it'll remove a couple of features though.
j.
On Thu, Jun 6, 2013 at 9:08 AM, Togan Muftuoglu <
[email protected]> wrote:
> On
On 06/05/2013 10:56 PM, jeremy rosen wrote:
> IIUC what hanatos said, it's not just a question of adapting. upstream has
> removed features that we need.
>
> so either we drop libraw entirely or we fork it entirely, but we can't use
> upstream because upstream has droped features we need.
>
> thi
On 06/05/2013 10:51 PM, johannes hanika wrote:
> On Thu, Jun 6, 2013 at 8:45 AM, Togan Muftuoglu <
>> If maintaining the fork is not worth maintaining, how about keeping upto
>> date with the current libraw, meaning adapting the code.
>>
>
> let me repeat this, they removed features we depended on
IIUC what hanatos said, it's not just a question of adapting. upstream has
removed features that we need.
so either we drop libraw entirely or we fork it entirely, but we can't use
upstream because upstream has droped features we need.
this is not a chage of API this is a change of feature
On W
On Thu, Jun 6, 2013 at 8:45 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:28 PM, johannes hanika wrote:
> > On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
> > [email protected]> wrote:
> >
> >> On 06/05/2013 10:15 PM, johannes hanika wrote:
> >>> just
On 06/05/2013 10:28 PM, johannes hanika wrote:
> On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
> [email protected]> wrote:
>
>> On 06/05/2013 10:15 PM, johannes hanika wrote:
>>> just for reference, it might be possible that reverting half of this
>> could
>>> make it work again.
>>
On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:15 PM, johannes hanika wrote:
> > just for reference, it might be possible that reverting half of this
> could
> > make it work again.
> >
> > a91165396a0a7b41e6f08847a5ac932110ae4ff8
> >
>
>
On 06/05/2013 10:15 PM, johannes hanika wrote:
> just for reference, it might be possible that reverting half of this could
> make it work again.
>
> a91165396a0a7b41e6f08847a5ac932110ae4ff8
>
You lost me here this belongs to which git darktable or Libraw
On Thu, Jun 6, 2013 at 8:14 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:08 PM, johannes hanika wrote:
> > changelog:
> > [..]
> > API changes:
> > [..]
> > 2. deleted (nobody uses those)
> >- LibRaw::dcraw_document_mode_processing (and respective C-API)
> >
just for reference, it might be possible that reverting half of this could
make it work again.
a91165396a0a7b41e6f08847a5ac932110ae4ff8
j.
On Thu, Jun 6, 2013 at 8:08 AM, johannes hanika wrote:
> changelog:
> [..]
> API changes:
> [..]
> 2. deleted (nobody uses those)
>- LibRaw::dcraw_d
On 06/05/2013 10:08 PM, johannes hanika wrote:
> changelog:
> [..]
> API changes:
> [..]
> 2. deleted (nobody uses those)
>- LibRaw::dcraw_document_mode_processing (and respective C-API)
>- [..]
>
> which means we can't update any more.
>
So how about providing an option to disable t
changelog:
[..]
API changes:
[..]
2. deleted (nobody uses those)
- LibRaw::dcraw_document_mode_processing (and respective C-API)
- [..]
which means we can't update any more.
j.
On Thu, Jun 6, 2013 at 2:51 AM, Togan Muftuoglu <
[email protected]> wrote:
> Tere's a double-fre
See subject. :)
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single
Tere's a double-free (fixed in 0.15.2[3]) and a buffer overflow
(fixed in 0.15.1[2]).
References:
[1]http://www.libraw.org/download
[2]http://www.libraw.org/news/libraw-0-15-1
[3]http://www.libraw.org/news/libraw-0-15-2
http://secunia.com/advisories/53547/
https://bugzilla.novell.com/show_bug.cg
for 2) the answer is probably that when you enable opencl you process the
image faster but you need to move your image to/from the CPU, which is
quite long
when opencl enabled modules are next to each othe in the pipe we don't need
to copy the image around, but when there is a non-opencl module, w
Hi,
Ok for this response but i still don't understand 2 problem with that :
1) module watermak on dev version is 3 times slower on the dev version than
the stable version :
stable darktable, module watermark with opencl : 0.476 secs
dev darktable, module watermake with opencl : 1.351 secs
On Wed, Jun 5, 2013 at 1:08 AM, Roumano wrote:
> Hi,
>
> (Only) just now (with the new ati-drivers 13.6) , I can enable the
> opencl on darktable
>
> [opencl_init] device 0 `Tahiti' supports image sizes of 16384 x 16384
> [opencl_init] device 0 `Tahiti' allows GPU memory allocations of up to
> 10
19 matches
Mail list logo
