I just wanted to give a little update incl. the code I use now to anyone who might be interested.
Thanks, it's always nice to hear how these things turn out
as you may notice this code contains lot of try and error information and it is somehow redundant, which is bad but I was not able to understand which if the luar or the ptp code was more dominant but at the end I end up using both.
I had quite issues with avoiding autofocus before each shoot. so that's why I used in addition to the ptp code also
FWIW, -sd=1495 -sdmode=MF should really be equivalent to the luar commands, but bugs are always possible.
A couple other comments.
If you want things to run more quickly, you can combine multiple luar commands. This probably doesn't matter much to you, but executing each luar can take 1/10th of second or more, so may be relevant in other cases.
This can be done by putting everything on a single line like
luar set_lcd_display(0) set_mf(1) ...
or, if it's too ugly in one line, in a lua file like
set_lcd_display(0) --switch of display during taking photos
set_mf(1) --set focus to manual
set_focus(1495) --set focus distance
...
which you can execute in the .chdkptp file with
luar <myfile.lua
The '<' here is interpreted by chdkptp, so would need to be protected from the shell if you used it on the command line.
This file must only contain camera side Lua commands, not chdkptp CLI commands like 'clock' or 'rs'
For comments, you can use # at the start of a line in a .chdkptp file to avoid sending them to the camera.
At the moment I use the rawopint v0.25 with rawopint_rs.lua from reyalp. Thank you very much for that!
FWIW, depending on settings, rawopint may set some of these values (like screen off, dark frame, focus), but the default is usually to leave at alone, in which case setting it beforehand like you are doing should work.
If you want, you could put this lua code in the rawopint_rs.lua glue script, there's no requirement it only contain settings. This would make your code run in the same script invocation as the rawopint code, which is needed for some overrides (but not any of the ones you are using, AFAIK)
You may be interested in the
bv_ev_shift options to handle sunrise and sunset.
It works quite good now, but I'm still trying to reverse engineering the value ranges of some parameters as I haven't quite figured out the correlation of some parameters form the value in the log and the one is defined in the config file. For example how the correlation between d_ev and ui_max_ev_change_e or ui_bv_ev_shift_pct and bv96. But time will tell.
It's a bit complicated, the values in the menu are set up to make it less inconvenient to enter in within the limits of the CHDK script menu, and then they are converted to values the script can use.
Initial conversion happens in the script code just below the header. Some additional conversions are done later, but in the rawopint_rs.lua glue script you must set the values as if they came from the CHDK menu.
See
https://chdk.fandom.com/wiki/CHDK_Script_Header#Lua_Shorthand_Parameter_Syntax for information about the script header / menu syntax.
To take ev change as an example, the CHDK script menu definitions is:
#ui_max_ev_change_e=3 "Max Ev change" {1/16 1/8 1/4 1/3 1/2 1}
This is an "enum" menu item, whose value is the 0 based index of the menu selection (1/16 = 0, 1/8 = 1 etc.) The values in the brackets are just display values in the CHDK UI, they don't end up in the ui_max_ev_change_e variable.
The following code:
ui_max_ev_change = ({96/16,96/8,96/4,96/3,96/2,96})[(ui_max_ev_change_e + 1)]
Converts it to an APEX*96 value, using the enum value as a lookup in a Lua array (1 based index), with the values expressed as fractions of 96 to make the conversion clear. So enum value 0 looks up entry 1 in the table which is 96/16 = 1/16th of t stop = 6 APEX*96 units.
All the variables prefixed with ui_ are either set from the CHDK menu (or, in your case, the rawopint_rs.lua glue script) or derived directly from them like the example above. I use the convention that _e is an enum as above, _t is table (where the .value member is the string value of the user selection), and everything else is a plain number or boolean.
Later in the script, these are passed to the various modules (mostly exp) with the init calls, often with additional conversion.
If you have a camera you can work with directly, you can see what values menu options produce by adjusting them in the script menu and then looking at the saved script configuration in CHDK/DATA/RAWOPINT.n (however, table values will only show the 0 based index of the table entry, not the string value)
I also tried raw shooting but I was not so successful as I needed. Exporting one dng file with RawTherapee would take on the old computer I'm using at leased 10 seconds and it completely crashed my computer several times. But I kind of like the idea of using RawTherapee for such tasks, thanks for the hint.
Yes, RawTherapee isn't lightweight.
