Re: [darktable-dev] How do you feel about code bounties ?
Hi Jo ! I launched a poll on the french community blog (darktable.fr) to see if a founding of some sort would get support from users. The poll has been up for 10 hours, we have for now 42 answers and the good news are : * 95 % of users are ready to put money in the project, * 2/3 would go for a feature-based bounty founding, 1/3 would go for a recurring crowdfunding (like Patreon/Liberapay), * the average contribution per bounty per founder would be 16 ± 15 € (average ± 1 std) summing up to 660 €/bounty in total * the yearly total participation per founder would be 62 ± 49 € summing up to 2545 €/year in total (for now) So my question is : if we were to secure a recurring monthly revenue to pay for seniors/core devs time, would they be able to clear some hours each month to review code contributions or mentor new devs ? Platforms like Liberapay allow easily (as far as I know) to split teams earnings between the team members. Also, if you trusted me enough to give me admin rights on redmine, I would be happy to merge duplicates or close the solved issues to make some room. Have a good day ! Aurélien. Le 10/09/2018 à 08:55, johannes hanika a écrit : > hi, > > thanks for putting this list together! yes we're terrible dealing with > these things. time seems to be the limiting factor here. the problem > with recruiting new people to go in and fix these things is that you > need someone to review the changes. which pretty much amounts to the > bottle neck for our github pull requests or google summer of code and > the like. now funding a full time employee for a secured amount of > time is a completely different story than fixing a bug here and there. > > i agree that the procedure needs to be changed though. somehow the > core issue seems to be senior dev time to me. > > cheers, > jo > > On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre > wrote: >> Hi everyone, >> >> looking at the Redmine feature requests, it seems that a lot of legitimate >> requests are left idle, and some have been so for several years, generating >> duplicates. Most of these features are cosmetic User Interface improvements >> or making variables writable, such as : >> >> delete some EXIF+GPS meta-data in exported files (for privacy) >> set the export file resolution from paper size and printing DPI, set the DPI >> value right in EXIF, >> add/edit unique names/titles for modules instances, also within styles, >> decompose the darkroom history by module AND module controls (decrease the >> history granularity), >> add more JPEG exportation options (progressive, optimized, subsampling), >> apply conditional styles automatically (the same way as the presets of the >> modules), >> make styles hierarchical (to clean-up the list), >> allow drawn mask edition (size, feathering, opacity) from the masks list and >> keyboard input values, >> lock position and size of drawn masks for safe panning/zooming, >> EXIF and IPTC management/edition requests (date, time, names of lenses >> without processor, scans with no/wrong metadata), >> create arbitrary collections/catalogs of images (ex : family, perso, >> assignments), >> implement ESC and RETURN shortcuts in every dialog to cancel and validate, >> implement a coarse/fine tuning option to increment/decrement values with the >> mouse wheel >> lots of small GTK glitches with scroll bars, lighttable selections and >> hovers, >> link exported pictures paths to original RAW files, >> allow to set the UI main color and create user-friendly theme/template >> (whitout editing CSS), >> etc. >> >> Some are more algorithmically challenging : >> >> make the RGB gains independant in wavelets/non-locals means denoising module, >> rotate/flip the sampling patch in the spot removal module and in the freshly >> merged retouch module, >> add a color correction on A and B channels to fix the desaturation happening >> in the local contrast module (laplacian) with heavy settings, >> display the locked AF point on previews >> detecting duplicates and similar pictures in database >> etc. >> plus all the Windows portability issues. >> >> And there are still #TODOs in the source code. >> >> Most of these changes are for sure not the most challenging and don't make >> for the sexiest coding party, so I have no trouble imagining how little >> appealing they can be to hobbyist developers, but they are nonetheless >> useful and game changing for professionnals who are bound to efficiency >> constraints. >> >> I find quite remarkable the dramatic improvements that software such as >> Blender have known in the past decade, and though I get why dt developers >> aren't thrilled by the admin overhead involved in a similar fundation to pay >> full-time developpers, I think the above requests will stay idle for some >> more time if we don't go next-level. That would be a shame considering the >> core is stable and sane, and what is needed is mainly cosmetic. >> >> As more and more
Re: [darktable-dev] Reverse mouse wheel scrolling direction
heya, sorry i don't know much about user interfaces and expectations. the scrolling is in line with what blender does for proportional edit for instance. sounds like it should be configurable. but i can't find such an option and i don't know enough about the mask code to be helpful here. cheers, jo On Fri, Sep 7, 2018 at 8:41 PM Aurélien Pierre wrote: > > Hi, > > I'm using a 3D (6 axes) mouse in dt on Ubuntu to zoom and set the size of the > drawn masks. On my system, I'm not using the natural scrolling, meaning that > the scrolling moves the view, not the content. > > In dt, I have to scroll to the bottom to increase the masks size (and scroll > to the top to decrease), which is quite disturbing. But on modules sliders, > scrolling to top increases the value as expected. > > Is there any way to reverse the wheel scrolling behaviour for masks only, in > order to make it consistent with the sliders behaviour ? > > Thanks, > > Aurélien. > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] More then one exporting thread
.. okay, it has been removed. iirc this is the loop that used to be parallel (needs some added sync inside): https://github.com/darktable-org/darktable/blob/master/src/control/jobs/control_jobs.c#L1236 -jo On Mon, Sep 10, 2018 at 3:26 PM johannes hanika wrote: > > heya, > > to tell you the truth i don't remember the state of the exporter. we > did have this option precisely for what you describe. one pixel > pipeline one GPU, and several for the export. i think it did lead to a > certain amount of race conditions for sequence numbers etc, and for > CPU based export, it didn't actually speed things up (in fact it > slowed it down). > > so the option was removed but it's possible that the backend still > supports it to some extent. even for multi-GPU setups our experience > back then was that export speed was much more io bound (read big RAW, > write full res high quality JPG..) than compute bound, so the idea > didn't receive much attention. today we arguably have quite a few very > expensive operations so we might want to re-evaluate this. > > cheers, > jo > > On Mon, Sep 3, 2018 at 8:09 PM Lutz Labusch wrote: > > > > Hi all, > > > > i want to say thank you for darktable, which is a pretty nice program, > > first. > > > > As a owner of two (n) powerful GPU devices it will be very interesting to > > have the possibility to have two (n) exporting threads for larger jobs. Is > > there somewhere an hidden option for this? > > > > Thanks and best regards > > > > ___ > > darktable developer mailing list to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] More then one exporting thread
heya, to tell you the truth i don't remember the state of the exporter. we did have this option precisely for what you describe. one pixel pipeline one GPU, and several for the export. i think it did lead to a certain amount of race conditions for sequence numbers etc, and for CPU based export, it didn't actually speed things up (in fact it slowed it down). so the option was removed but it's possible that the backend still supports it to some extent. even for multi-GPU setups our experience back then was that export speed was much more io bound (read big RAW, write full res high quality JPG..) than compute bound, so the idea didn't receive much attention. today we arguably have quite a few very expensive operations so we might want to re-evaluate this. cheers, jo On Mon, Sep 3, 2018 at 8:09 PM Lutz Labusch wrote: > > Hi all, > > i want to say thank you for darktable, which is a pretty nice program, first. > > As a owner of two (n) powerful GPU devices it will be very interesting to > have the possibility to have two (n) exporting threads for larger jobs. Is > there somewhere an hidden option for this? > > Thanks and best regards > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] debugging sqlite3 out of memory error
heya, this seems a bit hard to diagnose from here.. did you try to reproduce the exact sql query in the command line interface ( "sqlite3" ) ? you can see whatever dt does using "darktable -d sql". also did you start that from a clean database? for debugging, it may be helpful to backup your ~/.config/darktable/darktabledb and maybe even only run darktable --library /tmp/your-debugging.db on a one-time-use database so you're sure you didn't destroy it in the last run already. hope that helps, jo On Sun, Sep 9, 2018 at 2:12 AM Kael Shipman wrote: > > Hey all, > > I've been stuck with a sqlite error for a couple days now and figured it was > time to reach out to a broader audience. Something tells me this is probably > a simple error that's easy to solve and that I just don't know enough about C > debugging to figure it out. (I just learned about gdb today and started using > it to see what was going on, but get some weird behavior and didn't make any > headway.) > > A description of the error is here, but in short, I've created a very simple > test case that just calls the `dt_image_full_path` function and prints the > result, but when it calls that function, it gives a `sqlite3 error: out of > memory`. > > Any pointers would be appreciated. > > Thanks, > Kael > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] GMIC module
hi, On Wed, Sep 5, 2018 at 9:09 PM Heiko Bauke wrote: > > Hi Johannes, > > Am 05.09.2018 um 12:08 schrieb johannes hanika: > > > as to your question, integrate gmic or reimplement. does it make much > > of a difference? > > main differences: > > * using libgmic introduces an additional dependency. > > * libgimic is written in C++, GMIC module needs to be implemented in C++. okay those two i don't care much. this sounds more like free updates to the algorithms. we've had a few c++ modules, so no real show stopper. > > can the code run on cropped regions of interest and > > in floating point? does it work for preview, i.e. does a downscaled > > image look similar when processed to first processing and then > > downscaling? > > For the sharpening filters: At the moment one has to scale the preview > to the scale of the intended export to get an reliable preview. Taking > into account the scaling of the preview and scaling the parameters > accordingly would be easy. However, I am unsure, if applying the > sharpening filters with scaled parameters really gives a better preview. > When it comes to sharpening, I think one always has to zoom in to > adjust the parameter appropriately. Therefore I neglected this issue so > far. right. we do very similar things for denoising/sharpen inside darktable. this is just something that has to be considered. > > any performance concerns in the interface (need to copy > > buffers etc)? > > GMIC stores image data quite differently than darktable. Thus > additional copying steps are needed, which is not that so nice. that sounds suboptimal. but how much does it cost? did you run darktable -d perf with something very minimal just to benchmark the cost of the buffer copy? if it's in the single digit millisecond range maybe we shouldn't bother porting the code but just use the library.. > > for R/L sharpening, maybe that would be a popular addition to the > > current sharpen module (so it'll be easy to discover)? > > Completely agree. cool! cheers, jo ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] How do you feel about code bounties ?
hi, thanks for putting this list together! yes we're terrible dealing with these things. time seems to be the limiting factor here. the problem with recruiting new people to go in and fix these things is that you need someone to review the changes. which pretty much amounts to the bottle neck for our github pull requests or google summer of code and the like. now funding a full time employee for a secured amount of time is a completely different story than fixing a bug here and there. i agree that the procedure needs to be changed though. somehow the core issue seems to be senior dev time to me. cheers, jo On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre wrote: > > Hi everyone, > > looking at the Redmine feature requests, it seems that a lot of legitimate > requests are left idle, and some have been so for several years, generating > duplicates. Most of these features are cosmetic User Interface improvements > or making variables writable, such as : > > delete some EXIF+GPS meta-data in exported files (for privacy) > set the export file resolution from paper size and printing DPI, set the DPI > value right in EXIF, > add/edit unique names/titles for modules instances, also within styles, > decompose the darkroom history by module AND module controls (decrease the > history granularity), > add more JPEG exportation options (progressive, optimized, subsampling), > apply conditional styles automatically (the same way as the presets of the > modules), > make styles hierarchical (to clean-up the list), > allow drawn mask edition (size, feathering, opacity) from the masks list and > keyboard input values, > lock position and size of drawn masks for safe panning/zooming, > EXIF and IPTC management/edition requests (date, time, names of lenses > without processor, scans with no/wrong metadata), > create arbitrary collections/catalogs of images (ex : family, perso, > assignments), > implement ESC and RETURN shortcuts in every dialog to cancel and validate, > implement a coarse/fine tuning option to increment/decrement values with the > mouse wheel > lots of small GTK glitches with scroll bars, lighttable selections and hovers, > link exported pictures paths to original RAW files, > allow to set the UI main color and create user-friendly theme/template > (whitout editing CSS), > etc. > > Some are more algorithmically challenging : > > make the RGB gains independant in wavelets/non-locals means denoising module, > rotate/flip the sampling patch in the spot removal module and in the freshly > merged retouch module, > add a color correction on A and B channels to fix the desaturation happening > in the local contrast module (laplacian) with heavy settings, > display the locked AF point on previews > detecting duplicates and similar pictures in database > etc. > plus all the Windows portability issues. > > And there are still #TODOs in the source code. > > Most of these changes are for sure not the most challenging and don't make > for the sexiest coding party, so I have no trouble imagining how little > appealing they can be to hobbyist developers, but they are nonetheless useful > and game changing for professionnals who are bound to efficiency constraints. > > I find quite remarkable the dramatic improvements that software such as > Blender have known in the past decade, and though I get why dt developers > aren't thrilled by the admin overhead involved in a similar fundation to pay > full-time developpers, I think the above requests will stay idle for some > more time if we don't go next-level. That would be a shame considering the > core is stable and sane, and what is needed is mainly cosmetic. > > As more and more professional photographers adopt dt in their job and are > asking for more efficency-driven features, I know that some would be happy to > fund developpers to smooth all the sharp edges listed above. For now, the > features that the developpers don't need don't stand a chance to appear in > the software. > > So I found a platform where you could create a bounty for each feature > request/bug on Redmine, have users/donators fund the requests they want in a > crowdfunding way, hire freelancers to do it, and take care of the payment : > https://www.bountysource.com/. You can create a dt group, link it to Github, > open/accept/close/pay the bounties, etc. Actually, it seems that darktable > has already a project page, but only linked to the Github tracker : > https://www.bountysource.com/teams/darktable/issues. > > Shouldn't we merge Github issues and Redmine bugs/FR, and promote > bountysource ? > > Cheers, > > Aurélien. > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to
Re: [darktable-dev] An algorithm to downscale raw data BEFORE demosaic by whatever scale factor
hi! nice, your downscaled images look impeccable :) maybe they jump up or down by one pixel or so? do you have any example result images for the denoising already? are you running before or after black point subtraction? if you can, i think you should run before. exciting stuff :) cheers, jo On Wed, Sep 5, 2018 at 9:34 PM rawfiner wrote: > > Hi! > Some of you may now that I am working on a raw denoising algorithm. > One of the hard thing was that prior to demosaic, the algorithms are computed > on unscaled data, while after demosaic the algorithms can compute a preview > on a downscaled image, which is easier in terms of speed. > > So I tried to downscale the raw data, to be able to use that for preview. > There was 2 existing algorithm in darktable to do that (thank you Johannes > for showing me these algorithms!): dt_iop_clip_and_zoom_mosaic_half_size_f > for bayer files and dt_iop_clip_and_zoom_mosaic_third_size_xtrans_f for > xtrans files > My problem was that they only allow to downscale the images by a fixed factor > (2 in the case of bayer, and 3 in the case of xtrans). > > So I designed an algorithm, that work on both bayer and xtrans, and that can > be used whatever the scale factor. > The source code is available here: > https://github.com/rawfiner/darktable/tree/rawfiner-fix-downscale-algo > (commit 9992cf66fc8510f637e5e5f8ae26c49c2cba2eaa) > The graphic interface in raw denoise module is just here to be able to see > the effect of the algorithm in "fit to screen" zoom mode, and to activate or > desactivate the algorithm. It allows to compare what we get by downscaling > the picture before demosaic to what we would obtain without this downscaling. > The first slider controls the downscaling factor (0.25 means that width is > multiplied by 0.25, thus divided by 4) > The second slider is useless for now. > > I made a quick video to compare the algorithm with the existing ones, and to > explain how the algorithm work: > https://youtu.be/oE38w1YOhNQ > Sorry for the slow speed of speech, I am not used yet to do videos in english > ;-) > > You can also find some examples here: > https://drive.google.com/open?id=19xveG0EeF2RUjlRjDTs1AA9f-TnFZe2W > > cheers, > rawfiner > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
