Re: [darktable-devel] Fwd: Problem: Exporting takes long time & maxes CPU & RAM after last Linux Mint 13 Software Update

2014-04-02 Thread Mark Heieis
Hi, I have had the same experience. For me it seems to be related to enabling denoise (profiled). With denoise enabled export takes ~50s or more, without ~4s per image. I think this is to be expected. Although having said that, I've had a few occasions

Re: [darktable-devel] Proposal for a different cache setup

2014-04-02 Thread Pedro Côrte-Real
On Wed, Apr 2, 2014 at 1:34 PM, Pedro Côrte-Real wrote: > 1) A thumbnail mipmap cache, limited to a fixed max image size (say > 640x480) that gets calculated on-demand and never deleted. All these > mipmaps are stored to disk and a part of them is brought to memory as > needed to display. > 2) A f

[darktable-devel] Fwd: Problem: Exporting takes long time & maxes CPU & RAM after last Linux Mint 13 Software Update

2014-04-02 Thread Donal Buckley
Hi all, (First apologies if you've received twice email twice). I've been using darktable for over a year since about v0.9 and love it. Never had any issues. However since two weeks ago it has really become unstable or almost unusble when exporting jpegs. Haven't previously been on the mailing

Re: [darktable-devel] Policy as regards vendor-specific APIs

2014-04-02 Thread Benjamin Lefaudeux
Hi Johannes, it would just be an option to tick so that the eye tracking device is used to change UI reactions (hide panels when you don't look at them for instance). My issue is that there's no standard yet as regards eye tracking APIs, so I would hook to one from a specific vendor (not on a drive

Re: [darktable-devel] Proposal for a different cache setup

2014-04-02 Thread Brian Teague
On 04/02/2014 08:34 AM, Pedro Côrte-Real wrote: The proposal is to divide the cache into two: 1) A thumbnail mipmap cache, limited to a fixed max image size (say 640x480) that gets calculated on-demand and never deleted. All these mipmaps are stored to disk and a part of them is brought to memor

[darktable-devel] Proposal for a different cache setup

2014-04-02 Thread Pedro Côrte-Real
Hi everyone, Here's a proposal on how to improve darktable's caching. What this is trying to solve is: - The lighttable view is very slow at showing thumbnails for collections larger than the cache (see bug #9884). In fact it will thrash the whole cache while doing it. - To get full-size images i

Re: [darktable-devel] Policy as regards vendor-specific APIs

2014-04-02 Thread johannes hanika
heya, not sure i understand the question. you're planning to write a module for some special hardware? including drivers? -jo On Wed, Apr 2, 2014 at 12:47 PM, Benjamin Lefaudeux < benjamin.lefaud...@gmail.com> wrote: > Hi everyone, > congrats first for all the work you did on Darktable, awesom

[darktable-devel] Policy as regards vendor-specific APIs

2014-04-02 Thread Benjamin Lefaudeux
Hi everyone, congrats first for all the work you did on Darktable, awesome, it has been my RAW processing software of choice for some time now.. . I have a small question as regards your policy with respect to vendor specific APIs : I was planning on testing a UI modification in the field of eye-tr

Re: [darktable-devel] Small Bug report

2014-04-02 Thread Markus Jung
Hello Peter, thats a known issue which will be fixed in a future release if the internal scheduling has been rewritten. At moment there is no quick fix planned/possible (according to this list and freenode#darktable) Regards, Markus Am 02.04.2014 01:10, schrieb Peter Martischka / 马彼得: > Hi every