On a small set of pictures I build dt before mipmap changes (e28ebe698).
I created all the mipmap and exited dt.
I then built dt from master.
First run the mipmap was all displayed fine, I then existed dt and got
this in the console:
[mipmap_cache] serialization to
`/home/obry/.cache/darktable/
> "Ulrich" == Ulrich Pegelow writes:
Ulrich> Am 15.09.2014 23:42, schrieb parafin:
>> try now, should be fixed with 893b171b8531a5367a0c4039baa019027a2d1987
>>
Ulrich> Well, now it fails to compile for me on openSUSE 13.1 :(
Well for me it still the same
openSUSE_Tumblewe
Am 15.09.2014 23:42, schrieb parafin:
> try now, should be fixed with 893b171b8531a5367a0c4039baa019027a2d1987
>
Well, now it fails to compile for me on openSUSE 13.1 :(
In file included from
/home/pegelow/darktable/src/imageio/format/exr.cc:39:0:
/home/pegelow/darktable/src/control/conf.h: In f
try now, should be fixed with 893b171b8531a5367a0c4039baa019027a2d1987
On Mon, 15 Sep 2014 23:12:53 +0200
tog...@opensuse.org wrote:
>
> Hi,
>
> As you may know I provide nightly git builds of darktable for openSUSE and
> Fedora. However after commit
> g8b4217c the builds for openSUSE_12.3 12.
Hi,
As you may know I provide nightly git builds of darktable for openSUSE and
Fedora. However after commit
g8b4217c the builds for openSUSE_12.3 12.2 and Fedora 19 are failing
In file included from
/home/abuild/rpmbuild/BUILD/darktable-1.5.1816_ge1b2720_git/src/imageio/format/exr.cc:39:0:
/h
I have fixed one obiviously wrong thing in
https://github.com/darktable-org/darktable/commit/e1b27201024c56747e81c46b9594290f20e1899b
It was found by Pascal Obry.
So now code actually reflects comment.
// last resort mem alloc for dead images. sizeof(dt_mipmap_buffer_dsc) +
dead image pixels (8x
Am 15.09.2014 21:10, schrieb Roman Lebedev:
> Hi.
>
> As far as i am aware, struct dt_mipmap_buffer_dsc is *not* being stored
> in on-disk mipmap cache.
>
>
> Aside from that, so far i have no more ideas.
>
If you can't fix it you need to revert the one or two commits in
question. You just can't
Please see also remine ticket #10109. darktable just crashes for me on
start due to commit ffbec14de21b0d3cf0b77e040308134c49632c22.
Ulrich
Am 15.09.2014 21:05, schrieb Pascal Obry:
> (Roman, I CC you as this seems a serious regression).
>
> I think this is a big problem with the mipmap cache.
>
Hi.
As far as i am aware, struct dt_mipmap_buffer_dsc is *not* being stored in
on-disk mipmap cache.
hanatos agrees:
>From IRC: (from related issue -
http://www.darktable.org/redmine/issues/10109)
hanatos: hello. i have a question about on-disc mipmap
cache, struct dt_mipmap_buffer_dsc and DT_
(Roman, I CC you as this seems a serious regression).
I think this is a big problem with the mipmap cache.
$ darktable -d cache
tell me that I have 131072 bucket for cache level 0. My setting is set
to 4096 for the Mb for the cache in the prefs. All this is fine and was
always this way.
I have
Am 13.09.2014 um 00:20 schrieb
darktable-devel-requ...@lists.sourceforge.net:
> Send darktable-devel mailing list submissions to
> darktable-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/darktab
Hello Jeremy,
Not sure if there is a single function and I'm no expert on the mipmap
cache circuitry. But I know that
the following sequence does initialize the cache for the lightable preview:
dt_mipmap_buffer_t buf;
dt_mipmap_cache_read_get(darktable.mipmap_cache, &buf, imgid,
DT_MIPMAP_0,
lua can iterate on all images in the database, but can't invalidate the
cache/force a rebuild...
that's probably trivial to do, but I don't know how to add it...
if you point me to the (C) function to call I can easily add it to the
dt_lua_image_t API...
On Sun, Sep 14, 2014 at 4:48 PM, Pascal O
13 matches
Mail list logo
