Add optional ability to load/save image rank property from/to xmp
sidecar "xmp.Rating" and color property from xmp "xmp.Label" ignoring
the ones provided in the processing params file.
This behavior is disabled by default and an option under settings ->
file browser has been added to enable it.
When enabled:
* On load:
* rank and color are not read from processing params.
* rank is mapped from xmp sidecar file rating entry.
* color is mapped from xmp sidecar file label entry.
* On save:
* rank and color are saved to the xmp sidecar
* rank and color are also saved to the processing param (pp3) files to
keep them in sync
Rating mapping:
Since rating can be also -1 but rank only goes from 0 to 5, the -1 value
is ignored like already done when importing from embedded xmp data.
Color mapping:
XMP has no color concept, usually programs like digikam uses the label
field to write a color name ("Red", "Orange"). The problem is that this
isn't standardized and label can be any string. Additionally Rawtherapee
has 5 specific colors while other programs can have different colors
with different name so they won't be shown if they don't map to the 5
color names supported by rawtherapee. On save only the 5 color supported
by rawtherapee wil be saved.
Trash is kept only in the profile files for multiple reasons:
* There's no trash concept in xmp, there's the rejected concept assigned
to a rating == -1.
* We could map rejected to trash but in rawtherapee rank and trash are two different values and
an image can have both rank >= 0 and trashed set to true.
Using an unique value like rating for rank and trash (when -1) will
require changing the current rawtherapee logic.
* Also digikam only handles ratings from 0 to 5 (no -1) and handles
trash in its own internal way without reflecting it in the xmp
sidecar.
Add a Properties type that contains values for rank, color and trashed
Each value will also contain an edited flag.
The properties variable is used to store rank, color and trashed. They
are fetched from the proc params and will update the proc params when
needed.
This is the base for future implementations where some properties (like
rank) will be also retrieved from other sources like xmp sidecar files.
File browser thumbnails for raw images start with a minimally-processed
images. These images are cached and image adjustments are applied on
top. The black level is "baked-into" the cached image. Therefore, to
reflect the black level adjustments in the thumbnail, one of two options
are required:
1. Cache an image before the black level is applied and process the
black level on top of this image.
2. Recreate the base image with the new black level and cache it.
The first option yields better performance when the user changes the
black level. However, it requires other base adjustments to be applied
every time, such as the camera multipliers. The second option requires
the base image to be recreated every time the black level is changed.
This commit implements the second option. It minimizes code changes, and
therefore possible bugs. It does add a performance penalty when the
black level changes, but the black level adjustment is rarely used.
* Change Preferences for observer whitebalance
* Change label white balance preferences
* Added Preferences 2 parameters Whitebalance auto correlation
* Add Preference Temperature correlation - sort and tooltip
* Change to rtengine cmakelist
* Apply patch from Lawrence37
* Small comment code
* Change defaut order prefrences wba
* Added force extra algoritm to Preferences
* Harmonize itcwb sorted
* Add fields to Preferences Itcwb
* Change settings precision Itcwb in Preferences
* Change tooltip Itcwb preferences
* First stage Itwcwb settings in main with pp3 and selction in preferences
* Second stage Itwcwb settings in main with pp3 and selction in preferences
* Third stage Itwcwb settings in main with pp3 and selction in preferences
* Add itcwb_fgreen student - green optimize
* Add Itcwb green range
* Itcwb history msg - first tooltips
* Remove force-extra because always used
* reused force-extra to use entire CIExy for sampling datas
* Removed inwanted text in console
* Set sensitive for Itcwbframe
* Various change - comment ..
* Small code review - chnage tooltips
* Remove settings itcwb_delta in Rawimagesource.cc to simplify
* Remove Itcwb Observer - put a single observer for everything - general - itcwb
* Fixed conflicts in colortemp.cc
* Various change - fixed bug - simplify
* Fixed limits for settings pp3 - chnage tooltip
* Clean unused code
* Put itcwb_findgreen in GUI
* Added checkbox 'Low sampling' to find the settings of 5.9
* Set Observer to Observer 10° - preferences default
* Missing setting Low sampling
* Show white balance multipliers
* Change default settings - Itcwb_sorted
* Move observer from preferences to WB
* Make observer selectable for camera WB
* Ensure observer checkbox is in sync with PP3
* Set default ITCWB low sampling for PP3s from <=5.9
Ensure temperature correlation white balance algorithm 1 is used when
opening edits from versions 5.9 and earlier.
* Removed unused White-balance frame in Preferences
* Comment some GUI sliders checkbox
* Removed all GUI itcwb in preferences and whitebalance
* Removed forgotten code in preferences
* Remove labels tooltips history Itcwb
---------
Co-authored-by: Lawrence Lee <45837045+Lawrence37@users.noreply.github.com>
* Use mtime as fallback timestamp for files without EXIF data
As suggested in #6449, with date-based sorting it can be useful to have
at least *some* sort of time-relevant information for EXIF-less files,
to prevent them from falling back to getting sorted alphabetically all
the time.
This commit simply defaults the file timestamp to the file's mtime as
returned by g_stat. For annoying reasons, it doesn't suffice to merely
forward the timestamp to the FileData structs - we also need to keep
track of it inside FilesData to cover the case of a file with 0 frames
in it.
* Add DateTime to Thumbnail
Putting it here facilitate easier sorting without having to re-construct
the DateTime on every comparison.
To simplify things moving forwards, use the Glib::DateTime struct right
away. This struct also contains timezone information, but we don't
currently care about timezone - so just use the local timezone as the
best approximation. (Nothing currently depends on getting the timezone
right, anyway)
In addition to the above, this commit also changes the logic to allow
generating datetime strings even for files with missing EXIF (which
makes sense as a result of the previous commit allowing the use of mtime
instead).
* Implement file sorting in thumbnail view
For simplicity, I decided to only implement the attributes that I could
verily easily reach from the existing metadata exported by Thumbnail.
Ideally, I would also like to be able to sort by "last modified" but I'm
not sure of the best way to reach this from this place in the code.
It's worth pointing out that, with the current implementation, the list
will not dynamically re-sort itself until you re-select the sorting
method - even if you make changes to the files that would otherwise
affect the sorting (e.g. changing the rank while sorting by rank). One
might even call this a feature, not a bug, since it prevents thumbnails
from moving around while you're trying to re-label them. You can always
re-select "sort by ..." from the context menu to force a re-sort.
Fixes#3317
Co-authored-by: Thanatomanic <6567747+Thanatomanic@users.noreply.github.com>
See issue #4008.
The bug in cacheimagedata.cc was preventing correct cached thumbnail
loading, asking for a full processing at each loading of the directory.
The behaviour has changed slightly, so that clicking the menu item now resets
to the default processing profile specified in the preferences. If this
involves calling the custom profile builder, the behaviour is the same as
before. But this is a bit more general, in that it might also simply reapply
the static default profile, or regenerate the dynamic one (depending on the
user's settings)
This new slider in the White Balance tools allows to alter the computation of
the "auto white balance" by "biasing" it towards warmer or cooler
temperatures. The bias is expressed as a percentage of the computed
temperature, so that the resuling temperature is given by
"computedTemp + computedTemp * bias".
