-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
styles: enable built-in styles, add camera-JPEG styles #17073
Conversation
Tested. It works. Observations:
|
I didn't use a name like "camera styles" because we'd want to internationalize that, which isn't possible atm. That would of course be better. You can remove multiple styles at once by selecting them all before clicking on "remove", though you can't remove an entire virtual folder of styles by selecting just the top-level name. Copying to the user config folder before importing would have the same issue of re-appearing, though only when clearing the folder or using a new one with The results should look pretty close, as I tuned them up on the raw.pixls.us sample images. The biggest difference I'm seeing in the settings is the exposure compensation to match midtones to where the camera's tone curve puts them, which ranges from +0.3 EV to +1.6 EV, with most being +0.8 to +1.1. The styles are built with exposure, color balance rgb (saturation/vibrance), filmic rgb (global contrast), and local contrast modules. |
I can vouch for that :-)
If they are in the config folder the user owns them and should be able to delete them
If you are never going to use it? I could live with it (and if I got really annoyed I could fix it :-D). Others?
Colors looked pretty much spot on in my small sampling. I did notice the exposure changes. It should make the look like jpg crowd happy EDIT: I could make a lua script to go with it that runs on import and auto applies the "correct" style to the image. |
That would be a great addition, and would really make the look-like-jpeg crowd happy. BTW, it's occurred to me that only importing the styles to an empty config runs into the problem that users upgrading from a previous version will never get the styles unless they manually import them from the system folder.... I think if we want them auto-installed but user-removable, we need to flag them as user-removed in the database to keep them from being re-imported. |
Here's a script that you can play with. Works on import and has shortcuts for apply to collection/selection |
Updated to handle ICLE-9 series |
I took a look at the code (currently don't have Lua setup in dt). When I was generating and naming the styles, I wasn't thinking in terms of automatic name matching. It makes sense for us to discuss this so that the script won't need updating any time new styles are added... The main issue is of course the X-series styles; it wouldn't be difficult to just duplicate them for each known model, though that would mean potentially more maintenance in the future. I was also thinking of adding a "generic" style for each manufacturer (like I have at the top level) once I have a better sense of the typical settings for the maker. That would be a useful fallback when available. Other than the Ricoh/Pentax normalization, the maker normalization could be handled by storing the lowercase version of the maker as the key in the lookup table (the original case is already present in the stored value at the bottom level). Finally, shouldn't the required API version be the current 9.x rather than 7.0.0? |
I'm letting the style naming/camera mapping thing rattle around in my head to see if I come up with a better way to handle it Here's a dump of model and maker info from my play raw collection (nice diverse set of images for testing). Implementing a generic for each maker should be easy enough, just an else to the style check.
Maybe. Right now it would run on anything greater than or equal to 7.0.0 (dt 3.6.0). I didn't look at the styles to see if they are using any modules that require a specific version of darktable. Here's the API <->dt version list
Let me know where to set it. EDIT: If we're not using any really new modules, then users from earlier versions could just install the styles and still benefit from the scripts. |
Idea: Use the model name as a search specification, i.e.:
brackets around multiple choice
Specifics become before generics, i.e.:
I should be able to read that and build the lookup table from it. That way whenever the styles change I should just be able to pick it up without a code change. EDIT: Keep the naming to what |
Here's a sorted model list from my play raws |
Done. I verified that brackets and question marks in the name don't cause problems (they get replaced by underscores when generating the export filename). The bracket notation might cause a bit of confusion for less technical users, but it shouldn't be a big deal.
Standard procedure :)
Should be OK for the majors (Nikon never had a D60 despite using D40/D50/D70/D80/D90, presumably because Canon had a D60 first). Might be one or two collisions among the smaller manufacturers. |
It's not an issue of how new the module is, but of the module's parameter block version. So far, I've only used local contrast, filmic rgb, color balance rgb, and exposure. Filmic is using v7, which is definitely newer than dt 3.6 - 4.2 or 4.4? But even if I were using e.g. v5, dt would be writing v7-compatible parameter blocks. |
filmic V7 was dt 4.4. Set API to 9.1.0 |
Canon EOS RP needs moved above Canon EOS R? series EDIT The Sony I:CE-7 Mark 2 shows up as ILCE-7M2 (and 3, and 4, etc).
Do you want to rename or do you want me to fix it in |
Tested the on import case and it took 20 seconds to process 1044 images. |
The ordering you get is just whatever order the retrieval spits out, which is either lexical or whatever the ordering of the database records is. I haven't done anything to force a particular order. Lexical would make sense to see "R? series" before 'RP" since ASCII code for question mark is less than ASCII for P. I've been using whatever model name shows up in the image information module while editing the sample image from RPU to generate the style. I still have around 90 Sony models to generate styles for, so I'll take another look while doing them. I've realized that the per-manufacturer submenus are still unreasonably large for the major makers, so I'm planning on adding an intermediate level where appropriate (e.g. 'DC-TZ...' as parent for all the DC-TZ???? models). This won't be something that can be matched automatically, but it also will have no effect if youe script just ignores it. For example,
becomes
and the rest of the script should work unchanged. |
The problem is when you cycle through the matches, RP matches R? before it gets to RP. I'll figure out a way to reorder it. Probably a look back at the previous value and an insert above if necessary. |
Rebased and partially squashed. Done, at least for now. |
@ralfbrown : Stupid question maybe... But how those styles have been generated? |
By hand - I went through the raw.pixls.us sample images and visually matched against an extracted copy of the embedded preview JPEG (or TIFF, in a few cases). BTW, RPU has been down for at least a few days now.... |
You've made around 500 edits manually!!!!! That's a huge work. Not sure how close we are from the embedded jpeg, can't test but probably a nice first step for some users. |
Once I got a rhythm going, it took 2-3 minutes per camera. Most use I've ever made of snapshots :). For a lot of cameras, we'd need to address saturated blues being too dark to get closer to the JPEG (thanks to the camera matrix having a negative coefficient for blue's contribution to luma). Likely via an instance of rgb primaries that attenuates blue. A large fraction of the sample images simply don't have strong enough blues to verify and tune settings. |
add code to do localization of the vertical bar-separated portions of a style's name when displaying the style name and when building the menu or collapsible browser entries. Prefixing a name's component with "_l10n_" will request localization of the text following that tag.
The style quick-access button in darkroom view currently only supports two-level menus, which is completely impractical when the new 'darktable camera styles' hierarchy runs to hundreds of styles. This commit generalizes the menu building to go as many levels deep as the treeview which is built in the styles module in lighttable, so that the longest style menu is only as many items as a single camera manufacturer has models.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on some images. The result is clearly better than the default dt rendering but not always close to the camera jpeg. But that's not the point at this stage, this can be improved later anyway if needed.
I'll put the final touches on the script, test it, and add it. |
I'm not surprised, given a quick adjustment on a single example image. An updated style is something which users can very easily generate and contribute even if they aren't technically-inclined. |
@ralfbrown : Just noticed that now, the Style combo in the Export module is now unusable as proposing a flat list with all entries. Can you add a hierarchical view as you've done for the other parts in the UI? |
Will take a look, but probably won't get a chance until mid-week. |
Tested the script and cleaned up a couple of issues. Build a lookup table based on https://en.wikipedia.org/wiki/List_of_Canon_products to map styles to equivalent cameras
A little more cleanup and it should be ready to add |
I just took a quick look at the existing code in the export module. Unless there's some easy way to have sub-pulldowns in a combobox (which doesn't feel like something that would be supported), a different mechanism will have to do. I'm thinking of putting the currently-selected style in a label and having a clickable button that will pop up the menu hierarchy for the styles. We could use either a simple down-arrow as is used on comboboxes or the same icon used for the styles quick-access button in darkroom. The rest of the code should then basically just be re-using the existing multi-level menus attached to the quick-access button. |
Indeed, never seen that done.
Or just pop-up a menu for entries in the combo that are menu entries (that is, entry with sub-values. So in the combo we could have "darktable camera style", and by clicking on it we would open a menu (with sub-menu) as done for the darkroom style button bottom-left. Just thinking out loud... |
I'm not sure there's any non-hacky way to accomplish that, because it seems that Gtk's combobox functions just store the index of the selected entry, which then gets read in the callback function. Besides, the code to do the full menu hierarchy starting from a button is already in place.... |
That should only happen once unless you delete data.db. |
This PR adds startup code to load styles from
share/darktable/styles/
which are not yet present in the database, and also provides a set of styles to approximately match the look of camera JPEGs for most standalone-camera models for which samples are available from raw.pixls.us. Further, it updates the styles quick-access button in the darkroom to produce a full menu hierarchy on popup rather than collapsing everything below the top level into single huge submenus.The provided styles are all under a common
darktable camera styles
top level to avoid name conflicts. This name is localizable.This setup will allow us to accept user-contributed camera-match styles and ship them with future version of darktable.