RTProfileSelector v1.0.5

It’s been a while since I last updated my custom profile builder, and there are probably very few, if any, users of RTProfileSelector left. But, since recently I needed to improve logging and profile debugging for my own use, I thought I might as well create a new release and advertise it here.

RTProfileSelector release 1.0.5:

  • #3 - Improvements to logging and partial profiles debugging
  • #6 - Protection against invalid characters in file names for ISO and Lens profiles

Instructions on installation and use can be found here.

2 Likes

Hi Marcos, since RT has built in dynamic profiles I do no longer use your great tool.

Yes, dynamic profiles is the way to go for most users! They definitely cover most use cases, and there is little reason for anyone asking for more.

I’d be using them myself instead of my custom builder, if all EXIF fields I need for my rules were available in RT: vendor-specific tags for identifying things such as monochrome & colour modes for the various camera models I’ve owned, custom white balance values, etc.

Also cascadingly applying a series of partial-profiles containing certain individual keys inside a given profile section (leaving the other keys alone) is a useful feature of RTPS which helped me create a rather flexible workflow: the final generated pp3 profile is a composite of pieces from sections from various partial profiles, each triggered by different rules, applied in a particular sequence. But I could easily go without this, and use the built-in dynamic rules if I had access to more (especially vendor-specific) EXIF tags.

Partial profiles work also in dynamic profiles.

Yes, I know. Maybe I’m missing something here, since I haven’t done much testing with the dynamic profiles feature in RT. I was under the (possibly wrong) impression that the dynamic profiles feature in RT applied (by overwriting what section values where already applied) the whole sections contained in partial (or full, for that matter) profile files, meaning that any given section found in a .pp3 file, when applied through the chain or rules for a given image, would overwrite all keys in that section. RTPS always merges the keys when it processes a section, combining values from several files for the same section.

For example, the [Exposure] section may contain several entries:

[Exposure]
Auto=false
Clip=0.02
Compensation=0
Brightness=0
Contrast=0
Saturation=0
Black=0
HighlightCompr=100
HighlightComprThreshold=0
ShadowCompr=50
HistogramMatching=true
CurveFromHistogramMatching=true
ClampOOG=true
CurveMode=FilmLike
CurveMode2=Standard
Curve=4;0;0;0.050000000000000003;0.017144577454482151;0.12;0.056293599784506772;0.21799999999999997;0.17068922303460063;0.35519999999999996;0.41106299850999484;0.54727999999999999;0.7126570386677068;0.81619199999999992;0.9512966621491713;1;1;
Curve2=0;

But it is conceivable (and sometimes useful) that a user wants to just seletively enable or disable the auto-matched curves, or the exposure compensation, etc. In RTPS, for example, I have a partial profile that looks like this:

[Exposure]
HistogramMatching=false

This way, for certain kinds of photos, I want to automatically disable just the auto-matched curves, but I don’t care about the other keys present in the [Exposure] section. In RTPS, it’s possible to select this profile after all other partial profiles have been applied, and make sure only the auto-matched curve is disabled. All other entries in the [Exposure] section in the final generated .pp3 file are carried over from other “lower ranked” profiles.

This is where I may be wrong about how the dynamic feature handles partial profiles. Maybe the built-in profile selector in RT does the same as RTPS, merging section keys one-by-one, from several profiles, instead of overwriting the whole section keys as found in each partial profile file selected through the chain of rules.

Oh man! If EXIF information was available as part of the Dynamic Profiles Rules, this would blow my mind. I could do rules based on EXIF info as well. Like what kind of color profile was used, if it used some kind of automatic exposure recovery mode (i.e.: D-range in Pentax, Active-D Lighting in Nikon, etc.), & related to automatically apply a specific .pp3 file that I want to use. This would be the ultimate tool. :slight_smile:

Please be aware, that most camera settings are not reflected in the raw, but in the embedded jpeg only. So using that kind of information to switch between different profiles might lead you along a wrong path.

At least for Fuji Cameras most settings are written to RAW too in order to let the RAW converter know what the photographer has chosen.
Even film simulation and DR extension are there, detected face positions, white balance fine tuning and so on.
I don’t think Fuji is the only manufacturer to do so.

And additional values for dynamic profiles would be a great idea for me, but surely a nightmare for RT developers!

Marcos created years ago the RT profile selector which he announced a new version in exactly this thread.

The settings in RT are still available


So I would recommend test it!

On the RT Profile Selector page you find enough guidance to set it up correctly.

At least for Fuji Cameras most settings are written to RAW too in order to let the RAW converter know what the photographer has chosen.
Even film simulation and DR extension are there, datected face positions, white balance fine tuning and so on.I don’t think Fuji is the only manufacturer to do so.

Yes, same goes for all my Panasonic cameras: I have created profiles, which RTProfileSelector “selects” :wink: automatically to approximate several colour modes (“expressive”, “natural”, etc) as well as monochrome modes with some of the colour filter simulations built-in the camera (orange filter, yellow, etc). Works pretty well, if you can identify which EXIF tags contain the required information. So, for Panasonic too, this kind of information is available in the raw files, not only in the jpegs.

Hi,

No, not really. Dynamic profiles work exactly like you want them in this sense. It is true though that you can’t match on arbitrary exif keys

Dynamic profiles work exactly like you want them in this sense. It is true though that you can’t match on arbitrary exif keys

Great! Maybe some day the dynamic profiles will have all the “extended” tags as reported by Exiftool. I think I once suggested you that the tag selection could present a grid-like interface with such fields.

Selecting the tags is no problem, the problem is that we would need a DSL to specify how to use the tags to apply the rules. If the tag is a string, you might want regexp matching, but if it is a numerical value, you might want to perform some arithmetic comparison on it, and so on… Nothing difficult in principle, but tedious to write, and with only a very small target audience (who might be skilled enough to use a custom profile builder directly…).

If the tag is a string, you might want regexp matching, but if it is a numerical value, you might want to perform some arithmetic comparison on it, and so on…

Yup, that could open a can of worms… In RTPS I took some liberties with that, trying to “infer”/interpret numerical values in ranges, even fractions (such as “1/500” for shutter speeds) but the code was originally for my own consumption, and I wasn’t concerned with correctness or consistency as far as it did what I needed.