I don’t use fast export, but what I think makes it faster is that the images are resized first and then the processing is done on resized image instead of the full sized image. You can also ask fast export to skip some filters.
When you have something already in the processing queue, you can’t paste profiles, you have to remove them from the queue, apply the profiles, and then send them to the queue.
@vato. I would say a mixture of 1 and 2. There will be nothing to stop 4 creeping in from time to time. I am sometimes guilty of that myself. 
. Perhaps we could develop a specialist turd polishing algorithm… (I guess they exist in many forms already)
Hi everybody, and thanks for the suggestions! Here are a few comments/answers:
Not exactly. I did say that I will try to port RT’s one when it’s ready, but nothing more than that at the moment. Personally I’m happy with GIMP for this kind of tasks.
This is a good suggestion, I’ll see what I can do.
Not interested in this, sorry. If you need more than a simple file browser, I think you should look into an external DAM tool. ART is trying to work nicely with other tools (see more below).
Sounds reasonable, I’ll consider this as well.
I’ve just pushed a change that will allow you to do this, and actually more. Here’s a screenshot:
Essentially, this allows you to apply an extra (partial) profile to all the exported images, but without saving the changes to the raw file sidecar (the changes will still be saved to the output .arp). So, to resize everything that goes into the queue, just create a resize profile and select it there. Other things that you can do with this could include setting a different output color profile for exporting to different media, and so on.
I need to think about how to do this properly, whether to use paths or brushes, and so on. It might take a while…
Copying the mask parameters might give confusing results, as different tools are in different places in the pipeline, so e.g. the same lightness curve might produce a very different mask when applied in color correction vs. local contrast (for example). I agree that raster masks would solve this, but again I need to think about how to properly implement this.
If I had to answer in one line, I’d say “the kind of software that doesn’t get in the way”. Or, as I wrote elsewhere, “simple things should be simple, complex things should be possible”. Which, in my view, translates to the following concepts (but please remember they are somewhat vaguely defined…):
- a minimal set of tools, that do specific tasks, and are as orthogonal as possible
- as few parameters as possible
- no surprising behaviour. By this I mean that what a slider does should be easy to understand, and so to predict
- all the above, obviously, without sacrificing quality and/or flexibility.
Clearly, given that power and simplicity are conflicting requirements, all this is easier said than done, but the above are the idealized goals.
Can you be a bit more specific? ART already can pick up ratings, color labels, and metadata from digikam (assuming you use xmp sidecars to store them), what else are you missing?
I’m afraid I don’t understand this, sorry. You can already hide all the side panels, and you can make them smaller by decreasing the font size. The UI is supposed to work decently also on 4k screen (inherited from RT), though I have no way of testing that…
My camera doesn’t do tethering, so I’m afraid this won’t be easy, sorry…
I’d also like to have brushes rather than paths, but I don’t know how long this will take.
Can you provide some more details and use-cases? I learnt what a vectorscope is when I read your comments so I might be missing some background… 
4 Likes
It is something like a chrominance historgram. From every triplet of YUV (Or other definitions of Luminance-Chrominance type signals), the Luminance is dropped and the residual UV values are plotted on a 2D-plane. At (0,0) you have no saturation. At the borders of the this 2D-plane you have maximum saturation with the angle describing the Hue. It is similar to an CIE-XYZ plot where luminance values are out of plane values.
I think they originated in TV production for calibration purposes of cameras (Hue Angles and Saturations had to be consistent) and where easily derived from a TV signal an plotted with an X-Y-Scope.
Colorists nowadays might use them for selective color adjustments as it’s easier to see if/when you have for example complementary colors (or other color schemes) whether there is too much color-clutter in certain hue-ranges. They can come in handy for spotting out of gamut clipping, adjusting white balance when looking at a grey card or a grey-ramp. Skintones usually lie in a specific range of hues, which are indicated on good scopes as the ‘skintone line’…of course assuming standard illumination. And probably lot’s of other stuff I don’t know.
The variant mostly used in colorgrading programs like DaVinci Resolve is YCbCr I think…but probably a different variant for grading rec.2020 material.
Photographers never heard of it, Movie/Video colorists cannot understand how Photographers can live without it.
The extra beauty of a perceptually uniform variant would be: I know no professional program that has this, it makes judging of saturation much much less of a guessing game (even in comparison to YCbCr scopes). For the ‘standard’ Vectorscope: it can help teach the user what a tool actually does to the Chroma information of a picture (what does the channelmixer do in comparison to a desaturation).
Introductory Wiki-link (very basic):
https://en.wikipedia.org/wiki/Vectorscope
I probably forgot a lot of what and why’s, please chime in if you know more.
2 Likes
Very cool!
Hello @agriggio,
Can you provide some more details and use-cases? I learnt what a vectorscope is when I read your comments so I might be missing some background…
A vectorscope [1] has just been implemented in the upcoming version of Shotcut, an open source video editor, to be released shortly.
If I remember correctly, this same feature is already avalaible in Kdenlive as well.
Personally, I would really like to have a waveform histogram as well [3].
You can take a look at this discussion where jonatos pointed to the code used in Darktable (?) to implement this option [4]
[1] http://vanhurkman.com/wordpress/?p=2563
[2] https://github.com/mltframework/shotcut/releases/tag/v20.02.02
[3] Kdenlive/Manual/View Menu/Vectorscope - KDE UserBase Wiki
[4] Waveform histogram - #15 by dafrasaga
3 Likes
Thanks! I’ll have a look
1 Like
+1!
Maybe add a grid in the perspective correction tool to help the user to locate vertically and horizontally
Thanks very much Alberto for listening to our requests, much appreciated.
That resize option is fantastic, more powerful than what I was envisaging. Looking forward to trying it out.
As for the recursive search, if it’s not something you’re interested in, I totally respect that. I do actually use DigiKam, but don’t think it would help for the use case I was thinking of. I just wanted to view and apply some edits all at once to a series of images I had in several subfolders. I think the only way to do it currently would be to manually move all the images into the same directory, right? Or maybe your new Queue profile option might help with this…
For what it’s worth, I personally think ART already has a professional look and feel.
If you want to apply edits all at once, then maybe you use the CLI and some batch script? You first create an .arp profile with your edits, then you ask the script to got through each subdirectory and apply the profile through ART CLI.
Thanks for the tip. It’s just that the functionality already exists in ART using the Copy > Paste Partial feature. The challenge is just getting to view all the images you want to edit in the same window in the File Browser.
I also think the Metadata filters would be way more useful if they weren’t just limited to single directories.
I’m on macOS 10.14.6 so I just got to play with ART last night. I have recently moved most of my RAW processing to RawTherapee and am loving it. I discovered ART on the same day as the 1.0 release. Great job. Right off the bat ART loads quicker than RT. Other tools feel a lot snappier but this could just be physiological.
My understanding is that ART is a fork of RT 5.5? Are there plans to start merging in features from newer version (5.8). I really like the new “Capture Sharpen” feature introduced in RT 5.8. It would feel redundant for you to code new features when there is already work being done in RT.
I also noticed a lot of tools/features removed from ART that exist in RT. Example, in RT the Black and White tool includes a curves feature. I’m not sure if you removed this or if they did not exist back in 5.5 when you forked. I’d like the know the thought process as to why some features are not there if they were removed. Do some of these additional features make the application slow? I wonder if you could add the ability to turn features on/off depending on the end user’s workflow.
Another feature I though might be cool would be some sort of workspace/layout option similar to what Photoshop has. If you are not familiar, you can change your workspace and the tools and layout are presented in a different layout depending on the type of work you are doing. I may want to use a different subset of tools if I am working on portraiture vs street photography vs landscapes.
As a end user I would love to know what your plans are. Do you plan on trying to merge back into RT (if that is something the RT team is even interested, RawTherapee hint hint)? Are you think you just want to use this as a starting point to evolve into a standalone RAW processor? If you are going on on your own what changes / refactors do you think you want to do with the code base? How could other developers contribute? I like how you brought over some Darktable features and did some Digikam integrations… do you plan on making the app more modular so you could interchange code with other projects?
Thanks again for sharing your take on this project. I hope to see this grow (be it as it’s own project or as a push forward in the current RT or some sort of new thing that grows out of this from RT, ART, DT, DK, ect…).
Sorry, I didn’t know this. But I checked with the color labels and it seems that some work (there are more colors in Digikam). What doesn’t work are the color flags that have the following meanings in Digikam: red: rejected, orange: pending, green: accepted. In the xmp file the red flag appears as:
digiKam:PickLabel="1"
This is about first impressions, more than anything. When you open ART (RT is guilty of this as well, of course) the fonts are quite big, the icons are big and ugly.
For my installation I changed the font size and the theme to the one that @blackfoxx made and the result is already much more pleasing.
You don’t have to be sorry, we are all thankful for the great work you have already done. I hope some ART user, who lives close to you, is so kind as to lend you his camera with tethering capabilities… (hint, hint)
In fact the way @agriggio implemented RL sharpening makes it closer to RT’s Capture Sharpening than RT’s RL Sharpening. He even added “corner boost” allow more sharpening in (softer) corners of tie image. Unless you’re really pixel peeping, I’m sure you’ll have hard times to find a significant difference between ART’s RL sharpening and RT’s Capture Sharpening.
Agreed,
at 100% view they look equal concerning artifacts
at 200% view I can see differences
When exporting a lot of images in batch it’s quite handy that Capture Sharpening in RT is about 2 times faster than RL in ART when not using corner boost.
When using corner boost it’s about 3.5 times faster
One simple request. Color tab > Channel mixer. Please change the font color of the three channels to gray of something. They hurt my eyes and are difficult to read!
Hi,
lots of questions, let me try to reply…
Essentially, I have an obsession for frugality 
Or to put it another way, I removed everything that I personally considered not necessary. I understand that it’s just a matter of opinion though, but I am not interested in adding stuff back at the moment.
No, but the RT team is welcome to take whatever they want, and I am willing to help with the porting if they ask (they now this, indeed).
ART is already a standalone raw processor…
Well, right now this is a personal project, so there are no procedures in place… so, I’d say the best way to contribute is to fork and submit pull requests.
so, this sounds very digikam-specific, there’s no equivalent in ART, sorry.
Honestly, I never noticed this before, but now that you mention it, I agree
2 Likes
Hi Alberto,
I have a small request regarding the masks.
It would be really great to be able to name the different mask instances.
This would allow you to come back and tweak the settings, knowing which part of the image you’re working on, without necessarily having to show the mask to identify the area.
It would be a time saver when there are a lot of masks.
I don’t know, however, where the name might appear because there is little room in the mask window.
Maybe a mouse click to switch between the correction parameters/ and the mask name?
Thank you for perhaps considering my request !!
1 Like