Re: [darktable-dev] Code reformatting...
On 01.02.23 06:13, Bruce Guenter wrote: On Mon, Jan 23, 2023 at 11:19:52PM +0100, Pascal Obry wrote: This has nothing to do with display size. Do you know why news paper has small columns? Because it is faster to read, that is, the time to go from the end of line to the start of the new is far easier if the width is not too large. Actually, that's a bit of an urban legend. Actually, it isn't. I studied typography and worked professionally in the field for a decade. Just take my word for it. :) Newspapers have small columns because wider columns have more unused space, which means less space for other features and, most importantly, advertisements. I dunno how newspapers entered this. Take any book, scientific publication, etc. They all stick to this rules despite the complete lack of advertising space constraints. Recent studies point to reading speed going up as line lengths increase, though the effect is not huge. https://www.usability.gov/get-involved/blog/2006/08/line-length-and-onscreen-reading.html I call that BS until you show me a meta-study with overall non-contestable sample size and age distribution. 20 college students? Yeah, right. I would say there isn't a bigger age bias to be had than that. And the sample size ... let's not go there. ;) Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Code reformatting...
On 01.02.23 23:04, Mark Feit wrote: I don't contribute code to darktable often, but I do follow this list closely and feel the need to comment on this. Take it or leave it as you wish. Dito. Let me just clarify some perceived misunderstandings re. my previous comments. :) The darktable source code isn't prose and isn't consumed like it. I can all but guarantee that formatting it according to _all_ of the rules for typesetting text and forcing people to work with it would result in a lot of screaming. That's sad and if it were true I'd consider it rather as an indicator of what could improved than a counter argument to what I said. Google 'code as prose'. ;) A great example is the source to the 'Physically Based Rendering' book(s). See https://practicaltypography.com/line-length.html From that page: "If you plan to use indenting to distinguish sections or hierarchies within your document, take this into account when setting up the initial line length. [...] I agree, this is important. A good code formatter will have option to make sure that foremost the part of the line after the indentation counts towards the line length and the indentation either not at all or by some some function of its width. Modernity doesn't really make a difference here. Rust didn't invent bringing a formatter along with the language and it certainly didn't introduce forced formatting for commits. I don't recall saying it did in either instance so I'm not sure why you mentioned this. Nor what difference to the validity of what I said it would make in regards of whether language X or Y was first or shipped a formatter as part of the default toolchain (which is pretty much non-existent for C/C++). Formatting for comments is off by default in rustfmt btw. Most C does just fine constrained to 80. Most parts of darktable I've browsed through probably would, too. But... In 35 years of writing C and seeing C code in the wild, I've run into code bases where formatters constrained to short lines made them awkward and difficult to read. Constraining darktable's C code base to whatever length some other code base in some other language uses as standard is dogma-driven design and it's not helpful. I think Rust and C are very comparable in this regard indeed. After almost 35 years of C, 25 of C++ and three of Rust I feel eligible to be opinionated here. :) Especially since Rust encourages heavy code reuse through crates ('libs') and it is common practice to not omit the namespace when using such imported functions/types/methods. I.e. the 'identifiers may be somewhat long' issue is not uncommon in Rust code as well. The pragmatic approach would be to find something that works for *this* code base and *these* developers. I didn't mean to suggest anything else. I was merely pointing out that the reasoning Matthias used is flawed. As I am a lurker on this list and do not have to touch C code, from darktable or otherwise, at all or very often any more, I better shut up now. :] Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Code reformatting...
On 23.01.23 22:12, Matthias Andree wrote: While the idea is sound, 80 character wide lines seem so... 1980's. Do people still need to read and edit darktable source code on 640x480 displays? This has nothing to do with how many character fit on a line on any display and everything with legibility. Just because it's code doesn't mean rules discovered by typographers and used for typesetting text for centuries do not apply. ;) 45-90 chars/line is the suggested default for body text. See https://practicaltypography.com/line-length.html There are modern languages which enforce a unified code formatting style. Rust e.g. hast rustfmt which almost all projects run automatically, via githooks or the like. So Rust code is always formatted the same way which is extremely helpful when reading other people's code (which is, after all, what most software developers do most of the time, even if we hate it and hate to admit it even more). The relevant defaults in rustfmt are: comment_width = 80 (comments, i.e. text) max_width = 100 (code) That said, in three years of using Rust and seeing Rust code in the wild, I've never seen 100c/l ever reached because there are other rules in rustfmt that commonly prevent this. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
On 8.11.21 13:50, Coding Dave wrote: Is this a valid usecase? I mean do you really correct digital photos with exif information from before epoch 0? What is your usecase? I have tons of pictures from my parents from the 60's that I digitized and timestamped accurate to a month using estimates/labels on the negative roll. Didn't run into this because geotagging is always on the todo list but when I will get to it this will become and issue for sure. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Is it time for a major code overhaul?
Hello Paul. You raise some good points imho. However, what I am replying to here is solely the suggestion of using C++. You may of course choose to ignore my reply as I'm not a DT developer. I do have 25+ years of professional experience writing software for image processing/generation though. Most of it in C++. So maybe I'm worth listening to. Before I start: I think the choice of C was excellent one of Johannes – at the time. Today I would probably choose Rust for any sort of refactoring/architecture/API improvements of any C code base I can think of. Including that of DT. C++ – I do not even know where to start how bad an idea I'd consider that. But to add some context: There is an ongoing effort from people in the Academy of Motion Pictures Software Association (ASWF) to expose all functionality as C APIs. One reason is that all the libs ASWF hosts will be wrapped in safe Rust APIs. What's more: core OpenEXR, just for example, is just being refactored in C (current codebase is C++). These are people relying on such software like OIIO, OCIO, OSL, etc. to generate millions of images for motion pictures and series. They are turning their backs on C++. It's early days but ... go figure. My suggestion would be: make a nice, safe RUst API to allow people writing modules in that language. Then, if people really feel the need, refactor DT, bit by bit, into Rust. Starting with the most hard to read parts of the codebase that someone new may want to contribute to. Just my two c. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Introducing dtdocs
On 17.10.20 01:41, Mica Semrick wrote: You have specifically pointed out where you think markdown is falling short in this case. For me MD vs Sphinx is mostly about roles, extensions, citations, line comments, footnotes etc. that you have in Sphinx but not in MD. MD was designed for writing texts on the Web. ReST + Sphinx was designed for writing documentation. Here is a longer version of that, written by someone else: https://eli.thegreenplace.net/2017/restructuredtext-vs-markdown-for-technical-documentation/ With that said: I prefer MD syntax over ReST any day as long as it doesn't take anything away I think is standard for good documentation. E.g. being able to have an index auto-generated. Sadly it does. Worst, there is no real standard in MD. CommonMarkdown is different everywhere. Maybe a feature you grew fond of when using MD in Jupyter Notebooks' MD is not available on GiHub's MD etc. > Feedback is welcome, but please try to make it actionable. We're > aiming for improvement. With the above in mind – if I were to start a documentation project now I'd probably use this: https://myst-parser.readthedocs.io/en/latest/ Which is kinda ReST + MD having a baby. :) It would mean all the work you done could be used, mostly as-is. But you would have all the bonuses of ReST + Spinx on top that MD + Sphinx would not give you. Even if you switched from MD + Hugo to MD + Sphinx. Oh, and use readthedocs to handle building and serving. Because, again, that is an ecosystem build for serving documentation as static pages online. Hugo is nice but it was meant to build static websites. Which surely represent a superset, containing static online documentation, but broad enough that it will leave many things to be desired, sooner or later. And btw: https://darktable.readthedocs.io/ is available. ;) Beers, .mm P.S.: For context: I wrote software documentation in MD several times during the last decade. I wrote software documentation in ReST using Sphinx several time (that was before Sphinx added MD support). I also have BG writing docs in LaTex from way before. With that being said I feel entitled to be opinionated about the subject. And mind you, I am talking about the perspective of the writer, not the user. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Introducing dtdocs
On 17.10.20 01:30, Mica Semrick wrote: On 10/16/20 2:12 PM, Moritz Moeller wrote: THB I think Markdown is a tad limited for docs like this. Have you had a look at the site yet? Yes I did. Though I don't understand how that relates to the part of my reply you quoted. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Introducing dtdocs
On 16.10.20 19:16, Chris Elston wrote: Introducing dtdocs (https://github.com/elstoc/dtdocs)… This project is a complete rewrite of the darktable documentation in markdown, providing a number of advantages over the current user manual: Fantastic! I suggested using Sphinx a few years back but I got ignored. THB I think Markdown is a tad limited for docs like this. But if I have to choose between the old doc format and Markdown there is no question. It's one of the reasons I never contributed to the DT docs. That may change now. :] Big thumbs up!!! :) .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Massive rendering issues with UI fonts in Windows 10
On 18.7.20 19:18, Patrick Shanahan wrote: but you do not say what version of dt you speak, nor where/how you obtained dt and how you installed it, He is on Windows 10. See subject line of his message. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs
I'm running 3.0.2. on 10.15.5 w/o any issues since that DT version was released. Not sure though when I upgraded from 10.15.4. Maybe I had 3.0.2 already installed by then. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] HSL and RGB scene-referred space
On 10.4.20 11:27, Harold le Clément wrote: - Is this a real issue or is this a bad usage of darktable? I.e. shall we never have RGB values higher that 1.0 in the pipe? As a user I would expect to keep the dynamic range throughout the pipe for as long as possible. If a module clips it would actually help if this was indicated in the UI. Maybe with a little warning sign icon or the like, on the module. - In the case this should ideally be fixed, I see three possibilities, are there others? 1. Use another hue/saturation/lightness estimator: HSV (although value is really different than lightness) or LCh (probably a lot more computationally intensive), ... Yes, I would second looking into the cylindrical models, LCh/HCL/CIELab/CIELuv, as better alternatives (https://arxiv.org/abs/1903.06490). Just my two c. As I said, I'm just a user of DT. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] HDR and SDR
On 17.12.19 14:24, Andreas Schneider wrote: All TIFF files are currently set to SDR ... That doesn't make sense. I use 16bit EXR when grading 3D rendered stuff via DT but someone could as well use 32bit float TIFF. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] UI glitches
On 19.11.19 14:54, Patrick Shanahan wrote: ah, when lacking a proper response, divert attention to something else which is also irrelevant. That's exactly what you were doing since attachment file sizes are not a topic of this thread. Maybe you meant /dev/troll? ;) The first ting I learned when running my own software company was that it doesn't matter what channel users try to reach you. If they reach out to you to let you know about something that is broken or could be better, be thankful. They mean well. They care about the software you make for them. What can be better testament to the work you do? Aka: No need to be rude. Tell them nicely about how to reach you better next time. You can prepare a nicely written response that outlines Red Mine account/ticket creation and procedure that you can C into a reply or point them to a website that does so. That takes 20 minutes. Obviously doing so will remove the opportunity to be rude to new people on this list forever to a large degree. Maybe the latter is more important to some people than solving the issue they purport to have here for once. On a side note: What's exactly the problem with large file attachments in 2019 in the first world? Yes, it's a bad habit. Does it bother? :) My email client doesn't load attachments unless I tell it to. Most clients nowadays don't. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] basic adjustments
On 15.11.19 12:02, parafin wrote: I think these numbers don't have units, so why do expect them to mean the same thing in different modules, even if we ignore the pipe order? Because that's the most basic requirement of usability. That things named the same way act the same way and mean the same thing across a single app – at the very least. It's not promised anywhere in the documentation as far as I can see. I went through the Photoshop & Lightroom docs and I can't find any promise in the entirety of them that slider ranges of things sharing a name will match in range & effect. Yet they do. Go figure ... Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
On 6.11.19 14:35, Julian Rickards wrote: From my perspective, filmic2 isn't appropriate. I work in the publication services section of an Ontario (Canada) government ministry and when we assign "2" to a publication, "1" is gone and no longer available. That's the most entertaining reasoning for naming something I've ever read on a software mailing list. :D If the original filmic is gone from this version, then I would just name the new one filmic. If the original filmic will also be available, just like the various denoise modules, this new filmic should have an additional descriptor such as filmic rgb. How about naming the old module 'filmic (deprecated)' in the UI and the new one just 'filmic'. Behind the scenes (XMP etc.) they can be called 'filmic' and 'filmic2'. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
On 5.11.19 19:18, Nicolas Auffray wrote: Anyway, that's not ok as the new UI is now size adjustable (by using CSS, not have anymore hardcoded things and use emphasis sizes on most parts to adjust correctly). It seems to be a MacOS specific issue... It's not an issue for me but for a first time user ... they'd probably close the app and never open it again. :) I couldn't even resize the main window to fit my screen. It would lock at a width about 20% larger. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
On 5.11.19 18:42, I wrote: I have the crazy oversized UI issue on macOS again. :) Setting the bauhaus/scale in darktablerc doesn't help. Never mind, setting screen_dpi_overwrite to 80 made the UI kinda the right size (except side panels which I had to scale down to 300). .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
Thanks for the great work, guys! On 4.11.19 18:44, Pascal Obry wrote: The darktable 3.0.0rc0 release is out. [...] > This is the first pre-release, test it and please be sure to report issues you found. I have the crazy oversized UI issue on macOS again. :) Setting the bauhaus/scale in darktablerc doesn't help. I do have the Roboto font installed. https://pasteboard.co/IFjkPwp.png Shall I file an issue? .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Lenses in the Lens Correction module
I was under the impression any lens found in lensfun will be available in DT. I have a Samyang 85mm f/1.4 prime. Samyang is completely missing in the Lens Correction module but I see lensfun has many lenses from this vendor (and also this lens): https://github.com/lensfun/lensfun/blob/master/data/db/slr-samyang.xml Can someone explain? Cheers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
On 27.5.19 01:09, Šarūnas wrote: On 5/25/19 3:11 PM, Christian wrote: Hi, I re-did the test with the Fuji X-E2 version of the test-chart shoot and the skin colors are much better. This interest me to, however it is not obvious, what you [re-]did to get better colors. Care to elaborate? Thanks! He just used images from a different Fuji camera. This means DT will use a different matrix for the conversion. And it seems that matrix, the one for the X-E2, doesn't have the issues OP is seeing with the one DT uses when fed with images from an X-T3. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
On 24.5.19 19:26, David Vincent-Jones wrote: Raw is RAW without processing. It is up to you to manipulate the raw data to achieve the look that you want. [...] OP clearly said they had no modules that shift color turned on. The DT processed image clearly has green tint in the shadows. For giggles, I opened the image in RawTherapee and Capture One and neither shows any green tint. So the conclusion seems to be that something in DT needs fixing. Beers, .mm P.S.: I am always flabbergasted about the arrogance/passive aggressiveness regularly displayed by some people on this list. Particular when users report bugs or shortcomings of DT. DT is not perfect. No software is. Get over it. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] BUG in Exposure (DT 2.6.2)
Hey Chris, thanks for the bug report. On 8.5.19 21:48, Christian wrote: Hi, Bug in Belichtung-Module (Exposure) : [...] In short: GUI-state of the pipette-icon is not reflecting the real state. I created a bug in the DT tracker on Github for you -- https://github.com/darktable-org/darktable/issues/2540. Maybe you could add more details, e.g. on what OS and DT version you are? Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Lighttable/Selected/Duplicate broken in 2.6.2 on macOS?
Can anyone confirm this is or is just my installation? I get the message 'duplicating 1 image' but no duplicate ever shows up in my collection. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] where to discuss big changes
On 17.4.19 09:16, johannes hanika wrote: i second the 'getting old' bit. and i really like IRC. Maybe you misunderstood my message's intend? Yes, I too prefer IRC over any 'modern' chat client. But I agree with parent that it is not the right tool to discuss big changes. IRC has no history. IRC has no message threads. That's why I mentioned NNTP. E-mail is the 2nd best alternative. IRC isn't one at all. IMHO. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] where to discuss big changes
There is this thing called 'a news server' which has all of below but has infinite history (for free) and you can actually see who replied to whom before even opening/deciding to read a message. That feature alone makes a news server with a decent client (e.g. Thunderbird) a thousand times superior to something like e.g. Slack. And this stuff has been available since the 70's. For free. Maybe I'm just getting old. Just my two c. Beers. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] ATTENTION: darktable master may go unstable.
On 7.3.19 21:47, Pascal Obry wrote:> - mask history (that is a mask is now part of the history and when changed will not change the same mask in the same module in the history. - the possibility to have custom module order (with drag & drop) - a working color space Fucking amazing!!! So next DT will get a node editor? :] Let me know when this is merged, I want to try this immediately! Beers! .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Lens correction -- move image center feature?
I recently started using very shot fisheye lenses (12-14mm) for event photography. The idea is that you will never catch the right angle/composition/moment all together at a wedding/party etc. Afterwards, you undistort the images and crop to the region with the best composition, to obtain a FOV more like 35mm or 50mm. The problem is that you also want to shift the image around in the distorted space before undistorting & cropping. Not after. Basically change the center, before undistorting so you don't get the extreme proportional changes at the edges of the image (which may, because of the region you crop to, end up much closer to the center afterwards). Would it make sense/be possible to add a horizontal/vertical shift to the lens undistort module for this? If so, I'd create a feature request in the tracker with some example RAWs. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Suggestion for improving 'color zones' module
On 29.11.18 15:00, tikuisik wrote: [...] So my strong suggestion and desire for the future releases of darktable would be to change the curve system in the 'color zones' module. Another mathematical type of curve that could ensure zero bending in the outlying region, similar to Adobe's Lightroom or Blackmagic's DaVinci Resolve (where upon selecting a particular hue to change, 3 nodes appear, the 'active' central one and two outliers that do not allow the effect to spread beyond), would be the most welcomed change. +1. I often grade footage in Resolve and I'm missing this behavior/type of curve too, in DT. Another, related issue is the size of the widget though. It becomes fiddly to adjust this. If the view could be zoomed horizontally, inside the widget, that would be a welcome addition too. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] noise
On 5.11.18 09:34, Rolf Meyerhoff wrote: if you have followed the UI refactoring discussion lately then you will have noticed that the intended target audience for DT are programmers and graphics nerds who really know what each module does, [...] Rolf nails the issue. The basic problem this discussion is about is UX created by developers. Developers usually understand well what an algorithm can do. Let's call it the 'domain of possibility'. Users commonly only need a tiny subset of this domain. One that lets them converge /as fast as possible/ to /optimal/ results for the task at hand by manipulating the /least/ number of parameters. Note that with every parameter on must manipulate to get to an optimal result, the domain the user has to understand greatly increases. You are basically adding a dimension (!) to the parameter vector that governs the result. Most developers, if they can't decide how to map any of an algorithm's parameter automatically, to govern an optimal result, will just expose that parameter in the UI. You can look at this from two sides: laziness/ineptitude/reluctance to understand what problem the algorithm will solve for the user (vs the full domain of problems it can solve) or just giving 'more power' to the user because you shouldn't 'assume' what subset of the domain they actually need. The latter is commonly the excuse developers will give but from my own experience the main reason is ineptitude. It's just the difference between how an artist's/user's brain is wired vs a developer's. This is the single most common reason UX/UIs of software often suck(s): developer's don't understand that users want /less/ parameters. They naturally think that more power is good thing. That's why today UX has become a profession. UX people are commonly those that are technical enough to understand the domain and at the same time the results most users look for. They can map it to the needs of the user by producing a minimal UI that is abstracted away from the original algorithm. As DT's main user group are developers or at least people with much better than average understanding of the underlying algorithms this is not such an issue. See the screenshot of OP from RawTherapee. There is a single drop-down that disables the whole obscure set of parameters driving it's noise reduction algorithm and switches it to a mode where it chooses good parameters for the user. Aka: RawTherapee's noise reduction module seems to have a mode where it has /zero/ parameters the user must adjust, from the looks of it!!! Amazing, if this is true. This would be top notch UX. DT lacks this. By design. Whether this a is a good or bad thing is a different discussion. I have my own opinion about this. I urge interested parties to watch a talk on how developers make artists lives harder and how some companies (the speaker works for one) are trying to abandoning this practice. https://www.youtube.com/watch?v=-ihVkVqCOGc=youtu.be=287 This part of the talk made a lot of waves in the VFX world. The number of mails the speaker (a friend of mine) got form renowned industry professionals, seconding his findings, is overwhelming. This talk also contained a section where the speaker analyses how bad Autodesk Maya's UX is. It was cut by the sponsor, Foundry, because of their business ties with Autodesk. Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] possible data loss scenario
On 09.10.17 08:50, Alexander Rabtchevich wrote: Yesterday I almost lost a three-years work. [...] > If the mouse had shifted when I had been typing 1, I would not be able to recognize my selected works from 3 years anymore. So you are saying you do not have a backup? .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] cannot compile current git
On 28.1.17 12:06 , Roman Lebedev wrote: *Please* try building master directly. I did. Same error. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] cannot compile current git
I also have an issue. But it's a different one: [ 6%] Building CXX object src/external/rawspeed/src/librawspeed/CMakeFiles/rawspeed.dir/decoders/DngDecoderSlices.cpp.o /Users/moeller/code/darktable/src/external/rawspeed/src/librawspeed/decoders/DngDecoderSlices.cpp:435:31: error: no matching function for call to 'jpeg_read_header' if (JPEG_HEADER_OK != jpeg_read_header(, true)) ^~~~ /opt/local/include/jpeglib.h:1039:13: note: candidate function not viable: no known conversion from 'bool' to 'boolean' for 2nd argument EXTERN(int) jpeg_read_header JPP((j_decompress_ptr cinfo, ^ 1 error generated. I am currently building on the monochrome branch. I did git pull git merge origin/master git submodule update .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Rawspeed from subrepo doesn't find camera
On 6.1.17 17:33 , Roman Lebedev wrote: Note that I always convert all my original raws from the camera (.ARW) to DNGs and have done so from the beginning. Ah, well, i sure hope that you keep original ARW around :) No, I don't. I do not see a reason for it. So if I upload an example, I can't honestly tick the box 'The file is manually copied from card/camera, without using any software like Nikon Transfer.' because these files all went through Adobe DNG Converter. We have a sample SONY ILCE-7M2 ARW, but it is not under CC0. So if you can, please upload one ARW. (and do please check if there are any other samples you could share) I uploaded a .dng originating from a Sony ILCE-7M2 ARW. I will upload an ARW when I do my next shoot/ .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Liquify feedback
First of all: this looks awesome! It means yet another reason gone to exit DT and open Fusion or, worse, PS. Fantastic work. Some comments. The overlay looks nice but hides too much of what is going on in the image underneath. It would be great if - opacity of the color overlay in the circles (or even blend mode) - density of the arrows - color of overlay (I guess arrows and circles share this) could be adjusted. Maybe just add this the global prefs? Another thing is that often one spends a long time creating a spline mask for some effect. Then it not unlikely that there is a shared edge between that spline and some liquify effect. Being able to import from/export to the mask manager would be great thus. Another important feature is exchange of warp points/lines/splines between liquify instances. Maybe a global liquify manager would hold this data and each instance would just let you select which ones to use from the global list and add some local modifiers like strength (could be negative to allow inversion). Cheers, .mm P.S.: In the tool it says warps|nodes count: X|Y This is a bit confusing every time I read it because the '|' looks like an 'l' or 'I' or a '1'. how about: warps, nodes: X, Y or warps/nodes: X/Y ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Grayscale, Was: Contribution
Hey Wolfang, On 09/05/16 11:46, Wolfgang Mader wrote: Thanks for the literature. I will have a look at is at soon as possible, and will come back to you, once there is something do discuss. I'll have some B images to develop soon. Anything I could test already? :) .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Grayscale, Was: Contribution
On 08/05/16 15:10, Wolfgang Mader wrote: On Friday, May 6, 2016 11:03:18 PM CEST Moritz Mœller wrote: What is missing is porting one of the contemporary black and white conversion plugins to be available in DT. The monochromes module is just very ... traditional. Some of the recent papers have C code/Gimp plugins. One of them should be ported to DT. I nan send your some suggestions. Please do so. Meta paper, possibly interesting to see what is there and what makes most sense to implement: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3254613/ Meta experiment (has links to almost all the interesting papers). http://cadik.posvete.cz/color_to_gray_overview/ Interesting looking ones; ordered by year of publication: 1. [2008] http://cadik.posvete.cz/color_to_gray_evaluation/ 2. [2007] http://www.eyemaginary.com/Portfolio/TurnColorsGray.html Another two more recent methods that look quite interesting to me. Again ordered by year of publication. 1. [2012] http://www.cs.northwestern.edu/~ago820/color2gray/ (has source, license is fine for any purpose) 2. [2008] http://www.inf.ufrgs.br/~oliveira/pubs_files/MS_C2G/MS_C2G_page.html Probably, one would want more than one algorithm and then use instances and blending for best results. Much like the current Global Tonemap module. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Anyone with 30-bit color depth?
On 13/01/16 08:29, Roman Lebedev wrote: Hello, lists. darktable's support for 30-bit color depth was again brought up in IRC channel yesterday. As far as i'm aware, none of us developers has the hardware (videocard that supports 30-bit output + 30-bit monitor), so we have no means to test and develop needed changes. Isn't Johannes working @ Weta? There should be hardware like this there and maybe he could ask nicely to do some tests/dev on it, "after hours". ;) .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer
On 22/11/15 23:44, Caio S. Souza wrote: I took a look at this module's source code and identified the pieces that must be changed (including the opencl kernel). If you agree this feature is a good idea, I may help implementing it. What do you think? +1 .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] review
On 10/09/15 14:15, iormail2...@openmailbox.org wrote: > I was talking about extensive editing in GIMP/Photoshop after raw > developing. What would be great was a way to assign virtual copies of an image, each using different development settings, to layers of a PSD or XCF file. Then when I update a virtual copy, I would have an option to 'update' instead of 'export' and it would update the resp. layer in the PSD/XCF w/o touching any layer masks or layer order. Layers are identified through metadata, so if I rename the virtual copy or the layer in PS/Gimp (or change the ordering), the update can still work. This would make the DT workflow between those apps 100% easier. .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org