Re: [darktable-dev] release 4.2 is coming...
Thanks to all the contributors that make Darktable exists, and yes also you Pascal :) I can only add up to other participants comments on how good and up to closed and paid software quality it is, and how glad I am that such software exists on Linux OS. I hope I'll find the bandwidth to contribute again for some ideas I'd like to see coming into the UI to improve ergonomics. Cheers folks, Florian Le jeu. 15 déc. 2022 à 12:18, Maurizio Paglia a écrit : > Oh... by the way... I would like to thank Pascal Obry too :-) > > Il giorno mer 14 dic 2022 alle ore 21:07 Pascal Obry ha > scritto: > >> >> Hello! >> >> I'd like to take some time, while we are all waiting for the 4.2 >> release, to send you a little message about darktable. >> >> This release cycle has seen lot of improvements as previous releases. >> We had also some divergences with one developer and the signal sent was >> certainly not good or worrisome for some of you. >> >> Fact is that the team behind darktable is strong and working very hard >> in many aspects of the project. >> >> Some people gain more visibility because they work on GUI part that are >> directly visible by end-users. But there is also some people working on >> part of the code that you do not see directly but that makes darktable >> internal better. >> >> I'd like to thank Hanno Schwalm and Ralf Brown for their work on >> performances, tweaking OpenCL code path and OpenMP to use every cycles >> of your CPU. >> >> I'd like to thank Hanno Schwalm also for working on new highlight >> recovery algorithms. >> >> I'd like to thank Diederik ter Rahe for looking into Gtk issues and >> proposing a very impressive framework for shortcuts. And to achieve >> that, lot of code refactoring has been done. Some Gtk parts are looking >> like black magic to me :) >> >> I'd like to thank Roman Lebedev for the hard work in rawspeed. Without >> this project darktable won't be there. Also Miloš Komarčević working on >> rawspeed and many RAW formats support. >> >> I'd like to thank Victor Forsiuk for working on image input/output >> support and fixing a huge number of spelling typos. >> >> I'd like to thank Aldric Renaudin for the continued effort on the >> lighttable filters and UI. >> >> I'd like to thank Nicolas Auffray for taking over the UI effort and >> doing magic with CSS. >> >> I'd like to thank Bill Fergusson for maintaining the Lua framework. >> >> I'd like to thank rawfiner for checking noise profiles and making sure >> they are in good shape for integration. >> >> I'd like to thank Simone Gotti for working on a new lens correction >> method based on meta-data. >> >> I'd like to thank all the testers and reviewers (Chris Elston, Martin >> Straeten, parafin, Mark-64, and others) making sure we do not introduce >> more issues than we are fixing. Also thanks for Chris for reading my >> English in the RELEASE_NOTES and correcting it. >> >> I'd like to thank parafin and Bill Fergusson for creating the release >> binaries for MacOS and Windows. And Andreas Schneider as maintainer of >> the OBS platform for creating the GNU/Linux binaries. >> >> I'd like to thank Sakari Kapanen for helping with color science. >> >> I'd like to thank Jakob Andrén for the long journey at making Sigmoid a >> viable alternative to FilmicRGB. >> >> I'd like to thank all the translators bringing to us an interface in >> our native language. >> >> I won't name them, but also remember that darktable is Open Source and >> we leverage on many other Open Source projects/libraries (to handle >> Jpeg, TIFF, AVIF, HEIF, PNG... tether with camera, handle SVG, >> colors...). I'm even pretty sure that there is far more code in the >> dependencies we are using than in darktable itself. >> >> And finally I'd like to thank all people that I have forgotten in the >> list above. I'm sorry if I missed you. >> >> A darktable release is a huge amount of work and the darktable team is >> wonderful. I'm really happy to be part of it, let's the aventure >> continue. >> >> Have all a nice end of year! >> >> -- >> Pascal Obry / Magny Les Hameaux (78) >> >> The best way to travel is by means of imagination >> >> http://www.obry.net >> >> gpg --keyserver keys.gnupg.net --recv-key F949BD3B >> >> ___ >> 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] News about darktable 3.6
Any "forgot to press the shutter button" module planned ? Playing with the existing modules controls doesn't help much in improving the quality of my untaken shots :/ Florian Wernert Neuroscience PhD trainee Software engineer INSA https://www.linkedin.com/in/wernertflorian +33 6 51 23 69 35 Le jeu. 1 avr. 2021 à 21:07, Hubert Kowalski a écrit : > The "make image prety" button is planned for 3.8 afaik > > czw., 1 kwi 2021 o 20:29 Jan Ingwer Baer napisał(a): > >> I think the DT-devs are only gone half the way. The next step will be to >> remove all controls and set the selection of used modules and there >> parameter with a tiny AI. The only option for the user will be a button >> 'Next try' to run the AI again. >> >> On 01-Apr-21 16:49, Pascal Obry wrote: >> > >> > Hello! >> > >> > Some news about darktable positioning. >> > >> > The good news is darktable binary is now half the size of previous >> > release. Thanks to the removal of most superfluous modules that almost >> > nobody uses like velvia, tone curves, liquify... The GUI is now lighter >> > than ever. >> > >> > Some views have also been removed like Map, Tethering, Slideshow to >> > keep the most important ones. >> > >> > All remaining modules have also been revamped to remove many controls >> > and keep them usable by beginners (most dev modules have now one or two >> > sliders), the others parameters have good defaults or computed based on >> > the others. This will be a good ground to attract beginners, for hard- >> > core people it is highly advised to keep 3.4.1. >> > >> > These decisions are been made because the dev community is too small >> > and we cannot at this stage support all the base code. We have decided >> > to keep Windows for now but the MacOS port will be removed. >> > >> > The 3.6 release is still plan for end of June or very early in July. >> > >> > Regards, >> > >> >> >> ___ >> darktable developer mailing list >> to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> > > -- > Pozdrawiam, > Hubert Kowalski > > ___ > 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] Copy and paste settings
Ciao Lorenzo, The features already exists, it is on the light table in the right panel. Cheers Florian Le ven. 10 avr. 2020 19:30, Lorenzo Fontanella a écrit : > Copy and paste settings > It would be useful to have a copy / paste function of the settings from > one image to another, which includes the possibility of copying any vector > masks present on an image, without having to resort to saving a preset. > > This function of copying the masks is used when creating a variant of the > same image and modifying them later, both but in different ways, in order > to copy elements from one variant to another and vice versa. > > Thanks you > Lorenzo Fontanella > > ___ > 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] Moving left panel modules in the darkroom
Hey guys, sorry for the late reply, hard week at work last week. @David > > I have some other suggestions to get the user informed about the > potential signal processing disaster when ordering the pixel pipe modules > badly relatively to the color space. > > I would be very interested to read your suggestion. > This is really not the initial topic of my post but I guess sharing this could be useful. I think that starting by something as simple as putting a little sign like a yellow triangle with an exclamation mark in the title bar a module misplaced regarding what should be done for a regular image processing pipeline would be a good start. Hovering the triangle would display a tooltip explaining the issue and offering a link the the manual or and article on the topic for more detail. Otherwise the most straightforward thing would be to display an information message when the pipeline is "wrongly" ordered regarding image processing theory, using the user information mechanisms already present in the darkroom, maybe adding a "for more info click here" link in the message that would open the manual at this topic or opening a browser to the page of one of the several articles that have been produced on this topic. @jys > This might be enough, at least to start with. This is something most > people would want to change one time, if at all, right? > I would say that once they have been able to change and try between several configurations, they would indeed set it one time and don't touch it anymore. A file config would be a good first POC, but something more GUI doable, with a different user action to do it that the one allowing to reorder the pixel pipe, in order to avoid ambiguity between reordering the pixel pipe (right panel) and modifying the GUI (left panel). Florian Wernert Le mer. 22 janv. 2020 à 23:31, jys a écrit : > On Wed, Jan 22, 2020, at 07:33, Florian W wrote: > > > As an alternative, some config file based ordering of the left panel > > would be easier to achieve I guess (and safer considering your point > > #2). > > This might be enough, at least to start with. This is something most > people would want to change one time, if at all, right? > > -- > jys > ___ > 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] Moving left panel modules in the darkroom
Hi Aurélien, > Hi, > > image-processing modules *are not moved *up and down *in the GUI* but *in > the pixel pipe, *so that changes the actual order of application of the > corresponding filters. You are on for a lot of trouble if you handle that > as a workspace widgets reordering feature. > Indeed, I know as I read DT docs, articles, watch your videos and so on. And I didn't state that they are not moved in the pixel pipe, I mentioned that they are movable in the GUI (which will reflects on the pixel pipe ordering as you mention). But better saying it again and again as this information is really important from an image processing point of view. :-) Reordering the (non image-processing) modules as a workspace management > might raise 2 concerns : > >- a need for a global workspace/widgets layout editor (Qt app do that >a lot, GTK is not super keen), > > That's true, GTK is not as perfect as Qt for these UI design features. However the lack of such design tool what has been achieved for the UI part of moving modules in the right panel of the darkroom seems pretty good. There may even be some potential to factor it to other parts of the UI not linked to the pixel pipe. As an alternative, some config file based ordering of the left panel would be easier to achieve I guess (and safer considering your point #2). >- a possible confusion among users, because left panel reordering will >mean workspace reordering, but in right panel, it will mean pipe >reordering. 2 different behaviours for the seemingly identical graphical >widgets in the same app is not a good UX design. > > Very true that it is a possible source of confusion. Unless the users understand the consequences of what they are doing. I know you're very familiar with this question after having done a lot of user education material following the big change of pixel pipe free ordering (thanks for that BTW). The main question is to get the user informed of what happens by whatever means are available to the developers Which seems pretty achievable as differentiating between image processing and non image processing modules seems not to much to understand for a user. I don't mean to side track the discussion at hand here but if you're interested I have some other suggestions to get the user informed about the potential signal processing disaster when ordering the pixel pipe modules badly relatively to the color space. It would be useful to educate those who don't take time to read articles and videos about signal processing. Thanks for your useful inputs, Cheers, Florian Le 22/01/2020 à 14:33, Florian W a écrit : > > Hi guys, after a few months here is the usability nerd again :) > > I wondered if there was any reason (other than historical I mean) for the > ordering of the left panel modules in the darkroom. > > I can see good reasons to put the snapshot and history modules at the top > of the panel, however I'm a bit puzzled to see the mask manager at the > bottom and the duplicate manager at a higher position. > > Different people have different workflows and want to organize their > workspace differently according to it. > > Wouldn't it be great if the left panel modules could be moved up and down > like we can do in the right panel now? > > I mean, I usually use the mask manager way more often then the duplicate > manager (which I basically don't use as there's Ctrl+D to do the job). > > It's been a while since I haven't been into the DT code base but I shall > have a look to do that. > > Cheers and keep up the good work > > Florian > > ___ > 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Moving left panel modules in the darkroom
Hi guys, after a few months here is the usability nerd again :) I wondered if there was any reason (other than historical I mean) for the ordering of the left panel modules in the darkroom. I can see good reasons to put the snapshot and history modules at the top of the panel, however I'm a bit puzzled to see the mask manager at the bottom and the duplicate manager at a higher position. Different people have different workflows and want to organize their workspace differently according to it. Wouldn't it be great if the left panel modules could be moved up and down like we can do in the right panel now? I mean, I usually use the mask manager way more often then the duplicate manager (which I basically don't use as there's Ctrl+D to do the job). It's been a while since I haven't been into the DT code base but I shall have a look to do that. Cheers and keep up the good work Florian ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Camera-specific curves generation process
Hi there, Does anyone know if the procedure to generate the curves for a specific camera model is still up to date ? I took the instructions from here (5 years old though) : https://www.darktable.org/2013/10/about-basecurves/#comment-30544 and in the README of $darktable_src/tools/basecurve. I tried to generate curves for my Canon 750d with shots unfocused, both over and under exposed at the same time as instructed (see the jpg at https://ibb.co/C29R6Q9). And well... the generated curve is not very useful... see https://ibb.co/rG5yvnm Does one has to do a lot a sample shots (and maybe more diverse kind of shots) to get a correct result ? Or maybe someone has successfuly generated its camera's basecurve and can provide some guidance with this problem ? Thanks ! Florian Wernert Software engineer INSA Master in Neurosciences trainee https://www.linkedin.com/in/wernertflorian ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Printing: Using ICC profiles for papers
Maybe (just a guess) you would have better luck with HP printers as they provide their own proprietary drivers and printer control for Linux in the hplip suite. Le dim. 2 juin 2019 21:44, Pascal Obry a écrit : > > Björn, > > > So, does this mean that producing high-quality prints on Linux is > entirely impossible? > > Nothing is impossible. Solutions: > > - make you own profile > - ask a pro to do the profile for you > - use TurboPrint, high quality and properly supported by dt > > > In particular, I have two questions regarding the statement: > > > > 1. I am not sure wether I understand the explanation correctly. How > > exactly do the ICC profiles provided by paper manufacturers depend on > > the printer driver? Does the printer driver affect the printer's > > color rendition, so that the printer's color space when used with > > cups differs from the color space when used with the proprietary > > driver on windows? > > No, each driver use it's own algorithm to transform a RGB picture to a > print using 6, 8, 12 different color on your printer. The driver is a > software and the transformation done here is different on all OS. > That's why you have today ICC provided for MacOS and Windows. > > > 2. Is there any way to get properly color-managed prints with fine- > > art papers on Linux (with DT)? Would I have buy a > > colorimeter/spectrometer and profile it myself? > > The easiest solution is TurboPrint. I'm using it and I have implemented > the support in dt for a good reason :) > > -- > Pascal Obry / Magny Les Hameaux (78) > > The best way to travel is by means of imagination > > http://www.obry.net > > gpg --keyserver keys.gnupg.net --recv-key F949BD3B > > ___ > 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] Magnification of modules in Darkroom
Great! Thanks I didn't know Le jeu. 30 mai 2019 19:15, William Ferguson a écrit : > 2.7 already has histogram collapsing, CTRL+SHIFT+H > > > On Thu, May 30, 2019 at 12:54 PM Florian W wrote: > >> @julian >> >> Collapsing the histogram is also part of my bucket of features I would >> like to implement soon enough. >> I see that I'm not the only one often bored by the space it takes, even >> on a 24 inches display. >> >> I think it could be associated with a key shortcut as one still often >> have to look at it to control what he's doing. >> >> And at some other times I would like to be able to enlarge it as Giuseppe >> suggests for any module. >> >> I keep in mind your inputs regarding this when I'll be able to take some >> time on it. >> >> Le jeu. 30 mai 2019 15:18, Julian Rickards a >> écrit : >> >>> I use an older laptop with limited screen real estate and some modules >>> are quite large (height is the issue on my laptop) and any means of >>> improving this would be appreciated. I don't know if it would be part of >>> the consideration but sometimes (recognize that I'm not an expert at dt or >>> photography) I'd like to collapse the histogram to have more room. In my >>> experience, the histogram is not always necessary for all steps in the >>> editing process so the ability to collapse or open it as needed would help >>> with screen real estate. >>> >>> On Thu, May 30, 2019 at 4:51 AM Florian W wrote: >>> >>>> Hi Giuseppe, >>>> >>>> I also found myself thinking the same in some cases (for the histogram, >>>> for modules involving curves and nodes, for the fine tuning of a parametric >>>> mask...). >>>> >>>> I added this to my bucket list of features I would like to implement, I >>>> see I'm not the only one who miss it. >>>> >>>> Le mer. 29 mai 2019 18:08, Maurizio Paglia a >>>> écrit : >>>> >>>>> Ciao Giuseppe, >>>>> I have the same difficulty. >>>>> Please try to look the new dt GUI design because I think it could >>>>> solve this problem. >>>>> You can test it compiling dt 2.7 from source. >>>>> >>>>> Thank you, >>>>> Maurizio >>>>> >>>>> Il giorno mer 29 mag 2019 alle ore 17:30 giuseppe.in...@gmail.com < >>>>> giuseppe.in...@gmail.com> ha scritto: >>>>> >>>>>> Hello, >>>>>> I think it could be useful to have a feature that allows you to view >>>>>> a development module in a separate window with larger dimensions than the >>>>>> one currently planned. There are in fact some modules, such as the color >>>>>> zone (there may be other modules), with which it is not easy to interact >>>>>> precisely because of the limited size of the window on which to operate. >>>>>> Perhaps a button on the module's header is sufficient to display the >>>>>> module >>>>>> in a larger window. >>>>>> >>>>>> What do you think about this? >>>>>> >>>>>> Regards, >>>>>> Giuseppe. >>>>>> >>>>>> ___ >>>>>> 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 >>>>> >>>> >>>> ___ >>>> 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 >> > > ___ > 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] Magnification of modules in Darkroom
@julian Collapsing the histogram is also part of my bucket of features I would like to implement soon enough. I see that I'm not the only one often bored by the space it takes, even on a 24 inches display. I think it could be associated with a key shortcut as one still often have to look at it to control what he's doing. And at some other times I would like to be able to enlarge it as Giuseppe suggests for any module. I keep in mind your inputs regarding this when I'll be able to take some time on it. Le jeu. 30 mai 2019 15:18, Julian Rickards a écrit : > I use an older laptop with limited screen real estate and some modules are > quite large (height is the issue on my laptop) and any means of improving > this would be appreciated. I don't know if it would be part of the > consideration but sometimes (recognize that I'm not an expert at dt or > photography) I'd like to collapse the histogram to have more room. In my > experience, the histogram is not always necessary for all steps in the > editing process so the ability to collapse or open it as needed would help > with screen real estate. > > On Thu, May 30, 2019 at 4:51 AM Florian W wrote: > >> Hi Giuseppe, >> >> I also found myself thinking the same in some cases (for the histogram, >> for modules involving curves and nodes, for the fine tuning of a parametric >> mask...). >> >> I added this to my bucket list of features I would like to implement, I >> see I'm not the only one who miss it. >> >> Le mer. 29 mai 2019 18:08, Maurizio Paglia a écrit : >> >>> Ciao Giuseppe, >>> I have the same difficulty. >>> Please try to look the new dt GUI design because I think it could solve >>> this problem. >>> You can test it compiling dt 2.7 from source. >>> >>> Thank you, >>> Maurizio >>> >>> Il giorno mer 29 mag 2019 alle ore 17:30 giuseppe.in...@gmail.com < >>> giuseppe.in...@gmail.com> ha scritto: >>> >>>> Hello, >>>> I think it could be useful to have a feature that allows you to view a >>>> development module in a separate window with larger dimensions than the one >>>> currently planned. There are in fact some modules, such as the color zone >>>> (there may be other modules), with which it is not easy to interact >>>> precisely because of the limited size of the window on which to operate. >>>> Perhaps a button on the module's header is sufficient to display the module >>>> in a larger window. >>>> >>>> What do you think about this? >>>> >>>> Regards, >>>> Giuseppe. >>>> >>>> ___ >>>> 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 >>> >> >> ___ >> 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] DT bad on skin tones?
Thanks for this good suggestion Tim, I tried to do so (auto translated subs) for Aurelien's video on sharpness and local contrast, indeed it seems to produce an "accurate enough" result for a basic understanding. Le jeu. 30 mai 2019 14:31, a écrit : > If you decide to go the route of adding captions; here is the directions I > used for an internal video. Basically we used the generated captions; then > fixed them manually for any errors. The generated captions probably were > about 90% accurate. It was much faster than having someone manually do it. > > > > https://support.google.com/youtube/answer/6373554 > > > > Tim > > > > *From:* Matthias Andree > *Sent:* Thursday, May 30, 2019 8:09 AM > *To:* darktable-dev@lists.darktable.org > *Subject:* Re: [darktable-dev] DT bad on skin tones? > > > > Am 29.05.19 um 12:28 schrieb Aurélien Pierre: > > I guess I will have to record video tutorials in English then… > > Or find someone to translate French to English. > > Subtitles/captions have been proposed by Florian, too. > > > ___ > 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Magnification of modules in Darkroom
Hi Giuseppe, I also found myself thinking the same in some cases (for the histogram, for modules involving curves and nodes, for the fine tuning of a parametric mask...). I added this to my bucket list of features I would like to implement, I see I'm not the only one who miss it. Le mer. 29 mai 2019 18:08, Maurizio Paglia a écrit : > Ciao Giuseppe, > I have the same difficulty. > Please try to look the new dt GUI design because I think it could solve > this problem. > You can test it compiling dt 2.7 from source. > > Thank you, > Maurizio > > Il giorno mer 29 mag 2019 alle ore 17:30 giuseppe.in...@gmail.com < > giuseppe.in...@gmail.com> ha scritto: > >> Hello, >> I think it could be useful to have a feature that allows you to view a >> development module in a separate window with larger dimensions than the one >> currently planned. There are in fact some modules, such as the color zone >> (there may be other modules), with which it is not easy to interact >> precisely because of the limited size of the window on which to operate. >> Perhaps a button on the module's header is sufficient to display the module >> in a larger window. >> >> What do you think about this? >> >> Regards, >> Giuseppe. >> >> ___ >> 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
If there's some interest maybe i can dedicate some time to create English subs for existing good videos on Darktable from you, rawfiner, carafife... But not before July, I have a competition for a PhD grant at the end of June. Even though I prefer coding improvements :-P I already have a list of likely 30 items I would be glad to implement. They are mostly small stuff but important in term of UI usability. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
@Paul Appart from the manual, there's several people on youtube either presenting what you can do module per module and what effect on an image can be expected for each slider (technical approach), or doing screen recording of photographs edit (retouch/artistic approach) for a full processing or targeted to a specific issue (a common one : noise reduction). Some do both. It is advised to watch these in 1080p quality. Sometimes seeing the effect in live on several photographs of different type (portrait, street, architectural...) is really a good complement of the textual + photo description of the manual. Checkout (if not already done) Robert Hutton (english), Rawfiner , carafife and Aurélien Pierre (french if you speak it). Aurélien has a some video on filmic that are really helpful to understand the technical aspect of the module, which can be a good help for getting the result you want with it. I would be surprised that none of these resource have no equivalent in other languages too. For the retouch process, more based on what you want to improve rather than the tool to perform it, there's also a lot of information targeted to Lightroom users in textual and videos on the internet. Florian Wernert Software engineer INSA In-training Neuroscience researcher https://www.linkedin.com/in/wernertflorian Le mer. 29 mai 2019 à 07:00, Andreas Schneider a écrit : > On Wednesday, May 29, 2019 5:48:30 AM CEST paul sorenson wrote: > > This thread is fascinating to me. Are there resources out there for > > those who want to learn a more technical approach to editing with > > Darktable. As has been mentioned elsewhere, the manual kind of presents > > modules in isolation eg the base curve docs don't come with a warning - > > well maybe a hint in the tip at the end. > > > > I am using 2.7 built from source with base curve turned off but still > > tend to use filmic a bit by the seat of the pants. > > As always there are several ways to contribute to a Free and Open Source > project. If you're not writing code, writing documentation is a very good > way > to contribute! > > -- > Andreas Schneider a...@cryptomilk.org > GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D > > > ___ > 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] DT bad on skin tones?
" Sure, there are people who want to fight the theory of signal processing to complain about the consequences, and people who do the right thing at the right time in the pixelpipe. Surprisingly, the latter get better results faster. Thanks for trying to make my point a different one than what I expressed in order to dismiss it. I expressed that doing the internet equivalent of shouting by writing in capital is neither a particular strong way to make a point, to exchange with people, nor to help at the current issue with colors. I appreciate your work on filmic and I'm aware that basecurves are color inacurrate BTW. It doesn't allow you to lack some basic respect in your exchange with people you don't know anything about the background when it comes to signal processing, independently of how good you can be at it. Cheers and good luck in fixing the initial issue. Florian Le mar. 28 mai 2019 à 11:19, Aurélien Pierre a écrit : > Hi ! > > That falls back to the difference between Lightroom and Capture One > colors… If the in-camera software has been tweaked for warmer skins, you > won't get the same result with an all-purpose matrice alone. > > In color balance, push the highlights slider towards magenta (opposite of > green) with a small saturation, that should do the trick. Maybe do the same > in mid-tones, and push the shadows to green (to soften the shift). > > A. > Le 28/05/2019 à 10:52, Christian a écrit : > > Hello, > > :-) > > So I did a quick re-test on the X-T3 RAF. > > basecurve vs tonecurve (basecurve off) vs filmic (basecurve off). > > So, filmic is better but I could not completely get rid > of the green tint. > > Chris > > > > Am 28.05.2019 um 09:33 schrieb Aurélien Pierre: > > For the last time : > > *BASE CURVES ARE EVIL, CRAP, GARBAGE, NO-GO, DON'T TOUCH, BIO > HAZARD, KEEP AWAY, HUN HUN, SURVIVORS WILL BE SHOT AGAIN.* > > > ___ > > 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
Not everyone has the same approach of digital development (eg. Film like response vs more creative curve editing, with its disadvantages) and one of the strong advantage of Darktable is allowing all these use cases. Starting a war about this won't get us anywhere in the issue at hand here. Le mar. 28 mai 2019 09:33, Aurélien Pierre a écrit : > For the last time : > > *BASE CURVES ARE EVIL, CRAP, GARBAGE, NO-GO, DON'T TOUCH, BIO HAZARD, KEEP > AWAY, HUN HUN, SURVIVORS WILL BE SHOT AGAIN.* > > I wouldn't have taken 2 months of my life to develop filmic if base curves > had worked as expected. Base curves are a broken design and will always > destroy colors. I have repeated that multiple times in the past years, it > would be great if people started to listen. > > In darktable 2.8, there will be a global preference to have the base > curves disabled by default because they really harm, especially for the > newest HDR cameras. Until then, the first thing you need to do while > opening a raw picture is to disable that god-forsaken module manually. > > Thanks for confirming it has nothing to do with matrices though. That > means everything works as expected. > > Aurélien. > Le 28/05/2019 à 09:00, Florian Hühn a écrit : > > >> If RawTherapee is really using the same matrices, it would be interesting >> to find out what's being done differently (or additionally)... >> >> RawTherapee uses dcraw for import. I took the A7RIII testchart raw and > ran it through 'dcraw -v -w -o 1 -T DSC00157.ARW', then imported the .ARW > and the TIFF created by dcraw into DarkTable. The TIFF lokes more natural > to me. Especially the skin color of the guy on the right looks somehow a > bit yellowish / ill in the .ARW but more natural in the TIFF from dcraw. > BUT: When importing the TIFF no base curve is applied. When I disable base > curve on the .ARW and instead use levels and tone curve manually i can get > a look that is closer to the TIFF (i.e. the dcraw variant). > Maybe it comes down to different default settings in DarkTable importing > vs. dcraw. At some point I'd like to double-check that the matrix > calculations done by DT are indeed carried out as intended, but so far I > didn't find a way to artificially create a raw-file for this purpose. > > > ___ > 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 > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Options shouldn't be tied to Filmstrip
I'm not found on the idea of the style picker in dark room mode either. So far the philosophy of Darktable seems to be the darkroom is about photo editing, the light table is about management. Having something not related to the photo editing in the darkroom seems not appropriate to me. Le ven. 26 avr. 2019 22:14, William Ferguson a écrit : > > > On Fri, Apr 26, 2019 at 1:26 PM Julian Rickards > wrote: > >> In the top message in this thread, I did propose some options. Here they >> are again. >> - over/underexposure and raw overexposure with the histogram (I think >> Adobe Lightroom has the over/underexposure right within the histogram) >> - style picker removed and the Style module moved from the Lightroom >> mode to Darkroom mode >> > I use the style module in lighttable a lot. I have styles for noise > reduction, sharpening, watermarking, etc that I apply to large selections > of images all at once. I shoot sports and process lots of images. Applying > styles in lighttable mode speeds up my workflow tremendously. > >> - soft proof might be better to be within the Lightroom mode (but I'll >> admit that I've never used it) >> - gamut check might be better within the Input Color Profile module as >> it appears to be the module that can address any issues: the Perspective >> module has the option of identifying vertical and horizontal lines before >> you decide to apply a correction, the gamut check could work the same way >> in the Input Color Profile module >> >> I've never used the Presets quick picker and for the life of me, I can't >> remember what the 6th option is. >> >> On Fri, Apr 26, 2019 at 1:08 PM Patrick Shanahan >> wrote: >> >>> * Julian Rickards [04-26-19 10:42]: >>> > Ah, yes, that is a better description. >>> > >>> > However, I still maintain that they are not relevant to the film strip >>> > which (obviously) is part of the bottom panel but more relevant to >>> other >>> > components of the interface. >>> > >>> > Thanks for the correction. >>> > >>> > On Fri, Apr 26, 2019 at 9:38 AM Patrick Shanahan >>> wrote: >>> > >>> > > * Julian Rickards [04-26-19 08:54]: >>> > > > Hi: >>> > > > >>> > > > There are 6 options that appear below the main view window in >>> Darkroom >>> > > > mode: soft proof, over/underexposure, raw overexposed warning, >>> presets, >>> > > > access to styles and one other that I can't determine here. Access >>> to >>> > > these >>> > > > options are tied to the visibility of the film strip which I think >>> is >>> > > wrong. >>> > > > >>> > > > I believe that the over/underexposure and raw overexposed warning >>> buttons >>> > > > should be placed below or at the side of the histogram, it makes >>> more >>> > > sense. >>> > > > >>> > > > I believe that the Styles module in the Lightable mode should be >>> moved to >>> > > > the Darkroom mode and therefore the quick access to the styles >>> button on >>> > > > the film strip can be removed altogether. >>> > > > >>> > > > I believe that the Soft Proof button would make more sense in the >>> > > Lightroom >>> > > > module or perhaps below the preview window at the top left. >>> > > > >>> > > > I don't recall using the quick access to presets so I can't >>> comment on >>> > > that. >>> > > > >>> > > > And the last button, I'm not sure what it is. >>> > > > >>> > > > However, the main thrust of this suggestion is that visibility and >>> access >>> > > > to these options are tied to the visibility of the filmstrip which >>> makes >>> > > no >>> > > > sense to me. >>> > > >>> > > no, not the film strip but to the bottom panel. visibility of the >>> options >>> > > do not depend on the film strip being visible. >>> > > >>> > > bottom panel = >>> > > >>> > > -- >>> > > (paka)Patrick Shanahan Plainfield, Indiana, USA >>> @ptilopteri >>> > > http://en.opensuse.orgopenSUSE Community Member >>> facebook/ptilopteri >>> > > Registered Linux User #207535@ >>> http://linuxcounter.net >>> > > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet >>> freenode >>> > > >>> ___ >>> > > darktable developer mailing list >>> > > to unsubscribe send a mail to >>> > > darktable-dev+unsubscr...@lists.darktable.org >>> > > >>> > > >>> >>> yes, they are not relevant to the "film strip" and are not tied to it. >>> but they both exist within the bottom panel. if you believe they would >>> be better located, why, instead of just saying it is wrong, don't you >>> suggest "that better location"? >>> >>> instead of saying something would be better in a different manner, >>> suggest >>> the better manner so your suggestions can be followed. >>> >>> -- >>> (paka)Patrick Shanahan Plainfield, Indiana, USA >>> @ptilopteri >>> http://en.opensuse.orgopenSUSE Community Member >>> facebook/ptilopteri >>> Registered Linux User #207535@ >>> http://linuxcounter.net >>> Photos: http://wahoo.no-ip.org/piwigo
Re: [darktable-dev] Lens correction with FF lenses used on APS-C
Thanks for the details Simon. I also thought about it a bit and had a reasoning similar to yours, that basically something designed for a specific acquisition chain will probably perform worse on an acquisition chain farther from its spec. However thinking about it more deeply, 2 things are still boggling my mind. 1 This reasoning is mixing description of digital features with analog ones . A lens quality and specs is not defined by MP resolution (rather by like purity of the glass, glass curvature homogeneity, CoC, TCA, and so on). 2 Some of the lenses we're talking about were developed and (partially) targeted to FF cameras having a sensor with less MP than a current APS-C (for example in Canon, the 6D is a 2012 FF with 20MP). If the reasoning is valid, a lens released at times of FF with 24MP or higher wouldn't be a good match to the previous cameras with less MP. Which doesn't seems to be the case. What I mean by this is that at some point, to ensure a lens will perform well on FF cameras that will be released the following decade, one can assume that the optical manufacturing quality is probably one order of magnitude above the quality required to fit the current camera sensor capabilities. Maybe explaining why you can see problems in older lenses. Please feel free to point any mistake in this reasoning. Maybe are we lucky enough that someone working in the optical lenses or cameras industry is part of this mailing list and provide us some insights about it :) Florian Wernert Software engineer INSA In-training Neuroscience researcher https://www.linkedin.com/in/wernertflorian Le sam. 23 févr. 2019 à 18:12, Sturm Flut a écrit : > Hi, > > Am 23.02.19 um 16:34 schrieb Florian W: > > Thanks for your answers guys. > > > > Simon, I'm curious to know why to you it's not the best idea ? > > (oversimplifying it a bit) > > Full-frame lenses are designed to deliver their full sharpness across > the whole full-frame image circle. If I put a full-frame lens on my > APS-C D7100, I am basically expecting it to deliver 24 megapixels within > the smaller APS-C image circle the sensor is cropping out. That means I > expect the lens to deliver about 24*2,25 = 54 megapixels over the whole > full-frame image circle. Which not that many standard lenses will do. > > If put my standard 24-70/2.8 on a Nikon D850 and (let's say) it only > delivers 40 megapixels of actual resolution instead of the ~46 the > sensor wants, that's not going to be a catastrophe. If I put it on a > camera with a lower resolution sensor, e.g. the 24 megapixel sensor in > the D750, there is zero problem. But if I put the same lens on the > D7100, the cropped area will only get around 40 / 2,25 = 17 megapixels. > That's suddenly 30% less than what the sensor needs. And not every lens > will even deliver these 40 megapixels. Good APS-C and especially > Micro-Four-Thirds lenses are expensive and hard to make because they > have to be very sharp within the smaller image circle. > > Prime lenses are usually sharper to begin with, so with your 50/1.8 and > 28/2.8 it might not be that much of an issue. But I can clearly see the > problem with my 24-70/2.8, and especially with the good old 70-300/4.5-5.6. > > cheers, > Simon > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Lens correction with FF lenses used on APS-C
Thanks for your answers guys. Simon, I'm curious to know why to you it's not the best idea ? Le sam. 23 févr. 2019 16:19, Sturm Flut a écrit : > Hi, > > it does, as long as lensfun can find the lens in its database. I've been > using full-frame-only lenses on both my Nikon D750 (full-frame) and > D7100 (APS-C) for years. > > (It's not the best idea, though, so I'm about to replace the D7100 with > a second full-frame body). > > cheers, > Simon > > > > Am 23.02.19 um 14:42 schrieb Florian W: > > Hi, > > I happen to use on my Canon 750D (APC-C) 2 lenses designed for full > > frame (Canon EF 50mm f/1.8 STM and Canon EF 28mm f/2.8 IS USM) > > I wondered if the lens correction module takes into account that the > > camera is full frame or APS-C to apply the proper correction ? > > > > Can someone tell me ? > > Thanks > > > > > ___ > > 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
[darktable-dev] Lens correction with FF lenses used on APS-C
Hi, I happen to use on my Canon 750D (APC-C) 2 lenses designed for full frame (Canon EF 50mm f/1.8 STM and Canon EF 28mm f/2.8 IS USM) I wondered if the lens correction module takes into account that the camera is full frame or APS-C to apply the proper correction ? Can someone tell me ? Thanks ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
