Eh, sorry, I thought you are talking about preview, not thumbnail because I
did not understand how thumbnail could relate to the topic we were
discussing. Below are all lines from darktablerc relating to thumbnail:
plugins/lighttable/thumbnail_width=2560
plugins/lighttable/low_quality_thumbnails=FALSE
plugins/lighttable/thumbnail_height=1440

If you wonder why I have width and height set so high, it is because I use
monitor with this resolution.

Suni



2013/12/23 johannes hanika <hana...@gmail.com>

> could you please also answer the question about your settings re:thumbnail
> size? maybe you don't need the other switch at all.
>
>
> On Mon, Dec 23, 2013 at 12:42 PM, suni <s...@seznam.cz> wrote:
>
>> jo, thank you a lot for your hint. I lowered the downsampling
>> furthermore to 0.4 and now the preview process time is almost on pair with
>> full process time. This is huge improvement and finally what I was hoping
>> to. Having preview more coarse is absolutely no issue for me as I almost do
>> not use preview for navigation at all. In fact I do not realise any
>> visible difference in the image quality of the preview. I only realised
>> that downsampling lowered to 0.6 or 0.4 has some impact on zooming and
>> panning of the image. It is best visible when I do pan the zoomed in image.
>> In this case the image first zooms out itself, then it is panned and when I
>> release the mouse button, it zooms in itself again. So the image "jumps"
>> out and in during the panning. It is not much pleasant, but for me it is
>> acceptable tax for the improvement in speed. Moreover I do believe it could
>> be resolved at some point in the future.
>>
>> I would definitely vote for being able to set the downsampling rate in
>> darktablerc again as it was earlier. Thank you.
>>
>> Suni
>>
>>
>> 2013/12/22 johannes hanika <hana...@gmail.com>
>>
>>> your preview image will be a little coarser. i don't think it matters
>>> much. it's used to compute full-image histograms, for the navigation view,
>>> as well as for a quick preview while panning around in the image.
>>>
>>> -jo
>>>
>>>
>>> On Mon, Dec 23, 2013 at 10:44 AM, suni <s...@seznam.cz> wrote:
>>>
>>>> I lowered the downsampling to 0.6 and it helped a lot. Now preview runs
>>>> on CPU non-opencl device 2-3 times faster then on the same device earlier.
>>>> It takes some 0.5 - 0.6 sec and full on GPU opencl device takes up to 0.4
>>>> sec. Also subjective responsiveness of image editing is much better now.
>>>>
>>>> Does this change to downsampling have any negative impact?
>>>>
>>>> Suni
>>>>
>>>>
>>>> 2013/12/22 johannes hanika <hana...@gmail.com>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 23, 2013 at 5:22 AM, suni <s...@seznam.cz> wrote:
>>>>>
>>>>>> Thank you guys for your explanation. To be honest, your answers
>>>>>> disappointed me a bit. But I understand that we are talking here about 
>>>>>> too
>>>>>> much low level logic which darktable is based on so it cannot be changed
>>>>>> easily.
>>>>>>
>>>>>> Based on your information I think that one should change his mind on
>>>>>> what the most power demanding process of darktable is in fact. So far I
>>>>>> have been thinking that the most power hungry is processing of the full
>>>>>> pixelpipe. Therefore my strategy was to provide it the most powerful 
>>>>>> device
>>>>>> available. But now it turns out that it is not the case because the
>>>>>> bottleneck is preview pixelpipe instead.
>>>>>>
>>>>>
>>>>> what's your thumbnail size in your preferences excessively large? you
>>>>> might want to play around with lower values of
>>>>>
>>>>> src/develop/develop.c:53:
>>>>>
>>>>>   dev->preview_downsampling = 1.0f;
>>>>>
>>>>>
>>>>> and see if that still has an effect. i think it used to be a
>>>>> darktablerc parameter at some point, but not any more. not sure it even
>>>>> still works.
>>>>>
>>>>> -jo
>>>>>
>>>>>
>>>>>> I did a test and I found that my sample image is processed some 0.5
>>>>>> sec faster when I force preview to be processed on GPU opencl device
>>>>>> instead of CPU non-opencl device and full pixelpipe on CPU instead of 
>>>>>> GPU.
>>>>>> I tested on exposure, equalizer and profiled denoise modules. Half of
>>>>>> second on single edit may not look like a big deal, but considering how
>>>>>> much edits are usually done to process one image turns the situation.
>>>>>>
>>>>>> The strange thing is that my findings are in contrast to what is
>>>>>> written in user manual regarding the opencl default priority setting: 
>>>>>> "...
>>>>>> if there is only one GPU owned by your system, preview pixelpipe will
>>>>>> always be processed on CPU, keeping your single GPU exclusively for the
>>>>>> more demanding center image view.". Do you have any explanation why my
>>>>>> findings are different to what is written in user manual?
>>>>>>
>>>>>> Suni
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/12/22 johannes hanika <hana...@gmail.com>
>>>>>>
>>>>>>> we do, however, support several gpus and schedule several pixelpipes
>>>>>>> onto those.. at least for export that should work out of the box. has 
>>>>>>> been
>>>>>>> a while since i had a computer with > 1 gpu, so unsure what would 
>>>>>>> happen to
>>>>>>> the preview pipe. it's also a matter of not swapping in/out the sizable
>>>>>>> amounts of memory we require, so scheduling two pipes on one gpu at the
>>>>>>> same time might not be a brilliant idea.
>>>>>>>
>>>>>>> -jo
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 22, 2013 at 9:17 PM, Ulrich Pegelow <
>>>>>>> ulrich.pege...@tongareva.de> wrote:
>>>>>>>
>>>>>>>> Nope, this is not possible without changing significant parts of
>>>>>>>> darktable's architecture. darktable is event driven which means that
>>>>>>>> there is no single place in code where any reliable synchronization
>>>>>>>> between pixelpipes could be managed.
>>>>>>>>
>>>>>>>> Ulrich
>>>>>>>>
>>>>>>>> Am 22.12.2013 00:13, schrieb suni:
>>>>>>>> > OK, it seems that preview processing cannot be avoided, at least
>>>>>>>> for
>>>>>>>> > now. But would it be possible to let it process on the opencl
>>>>>>>> device
>>>>>>>> > instead of the much slower CPU while keeping processing full
>>>>>>>> pixelpipe
>>>>>>>> > on opencl too. It means to let process full and preview in
>>>>>>>> sequence, not
>>>>>>>> > in parallel? It should improve the responsiveness of every single
>>>>>>>> image
>>>>>>>> > edit at least in case only one fast opencl device is available.
>>>>>>>> There
>>>>>>>> > could be a configuration parameter to manage this behaviour. In
>>>>>>>> case of
>>>>>>>> > only one not very fast opencl device or two fast opencl devices
>>>>>>>> it still
>>>>>>>> > may be a good idea to let these two pixelpipes run in parallel as
>>>>>>>> they
>>>>>>>> > do now. I think there cannot be one optimal setting for everyone,
>>>>>>>> it
>>>>>>>> > depends on particular system configuration.
>>>>>>>> >
>>>>>>>> > Suni
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > 2013/12/21 johannes hanika <hana...@gmail.com <mailto:
>>>>>>>> hana...@gmail.com>>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >     On Sun, Dec 22, 2013 at 1:52 AM, suni <s...@seznam.cz
>>>>>>>> >     <mailto:s...@seznam.cz>> wrote:
>>>>>>>> >
>>>>>>>> >         Thank you Tobias, I was not aware of that. But anyway it
>>>>>>>> sounds
>>>>>>>> >         a bit strange to me. Why should any module depend on
>>>>>>>> preview
>>>>>>>> >         window which carries a lot less image information than
>>>>>>>> the main
>>>>>>>> >         image? I can imagine that it may be some remain from past
>>>>>>>> when
>>>>>>>> >         opencl was not implemented and cpu code was not so
>>>>>>>> optimized as
>>>>>>>> >         it is now. In such situation calculating the histogram
>>>>>>>> from
>>>>>>>> >         preview may be huge speed benefit. But I am not sure if
>>>>>>>> such
>>>>>>>> >         strategy is still valid even nowadays.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >     absolutely still valid. if you have a full hd monitor and a
>>>>>>>> 25MP
>>>>>>>> >     image, you leave > 20x performance lying on the table. and we
>>>>>>>> have
>>>>>>>> >     some modules which are still only borderline acceptable in
>>>>>>>> response
>>>>>>>> >     time, even if you just process one megapixel instead of the
>>>>>>>> full
>>>>>>>> >     image. to get a feeling for it, just export a full res
>>>>>>>> picture, that
>>>>>>>> >     will not run any preview pipe, only one full-size pipe.
>>>>>>>> depending on
>>>>>>>> >     your history stack that might take around 30 sec..
>>>>>>>> >
>>>>>>>> >     j.
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Rapidly troubleshoot problems before they affect your business.
>>>>>>>> Most IT
>>>>>>>> organizations don't have a clear picture of how application
>>>>>>>> performance
>>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility
>>>>>>>> into your
>>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>>>>> AppDynamics Pro!
>>>>>>>>
>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>>>>>>> _______________________________________________
>>>>>>>> darktable-devel mailing list
>>>>>>>> darktable-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Rapidly troubleshoot problems before they affect your business. Most
>>>>>>> IT
>>>>>>> organizations don't have a clear picture of how application
>>>>>>> performance
>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility
>>>>>>> into your
>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>>>> AppDynamics Pro!
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> darktable-devel mailing list
>>>>>>> darktable-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Rapidly troubleshoot problems before they affect your business. Most
>>>>>> IT
>>>>>> organizations don't have a clear picture of how application
>>>>>> performance
>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into
>>>>>> your
>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>>> AppDynamics Pro!
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> darktable-devel mailing list
>>>>>> darktable-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel

Reply via email to