..but you'll never render images with that resolution because there's
always a border around what dt displays, right?
the floating point cached image has the same size as the largest lighttable
thumbnail, to allow smoother transitions between lt->dr (the image will
appear in exactly the same spot, same size, if your panel configuration is
the same).
so lowering that at least to something you actually get on screen would
also help performance.
i do agree though that this downsampling factor is something that could be
a good idea to expose in the config (and it used to be at some point). we
probably removed it because of the zooming problems you describe, though
that used to work at some point, too. so let's wait for the release and
then we can look into fixing this again.
cheers,
jo
On Tue, Dec 24, 2013 at 12:24 AM, suni <s...@seznam.cz> wrote:
> 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
