thoughts on hdri on stages

some further work on the whitepoint panel, but I got sidetracked a bit this week on another
project wich is only midly connected to this one

- dmx whitepoint panel now works inside lightsmith and sIBLstage as expected
- some bugfixes
- output values of the color grabber are now displayed for manual adjustment
(RHB and HSV values)

auto whitepoint calibration:
Does not work as expected, not sure what the bug is, I suspect that the image noise
of the video does interfere with the gradual downstepping of each channel, but even with multiple readouts
some corrections in the frame grabber code and using a bigger step size I still don't get the result I want.

Also it needs a readout of the dmx values if you want to control the lights with a different dmx controller afterwards.

Manual whitepoint adjustment works though, and my horrible lights actually got a significant better Ra readings out of it than
measuring the white channel only....(but this means nothing, since the value go from horrible to less horrible...
would be cool to see if there is gain in the color rendering index if I would use serious good lights, but these are outside
my budget anyway. and as said numerious times, the selection of lights I do have at hand are ideal to face and beeing forced
to remove problems I would not think of, if my lights just work as expected.

But in general I like the concept of the panel, there are some interesting potentials for other tools, like adjusting all
lights in a dmx rig to a neutral output, or using harmonic color theories on selected lights etc....but thats for another project
Or for some 2.0 enhancements.

Anyway a video showing the failed and slow autmatic color adjustment (yes it needs a progress bar) and manual adjustment can be seen here:
...so not crossing out the whitepoint panel from my todo list yet, but its a step forward.

But if you got other things to do you can ignore this video.

Idea while eating:

Behavioural Change in the lightsmith architecture proposal:
If a lightsmith is imported in a program x, it should:

- lookup the obj filename,
- split the obj extension and add the program specific ending of the native object format of program x
- try to find a file with the specific ending in the lightsmith folder and load it instead, if no file is found use the obj as a failback.

This also goes for sIBL format in general (future enviroment models).  By using it that way you can slowly expand your siBLsets when you get access to a certain software or other people want to expand an existing set.

The more I think about it, the more I like the idea: it should be quite easy to implement and have a high return value
in quality and workflow.

Again not dead yet, but I had some other projects
and I'm also in the middle to do some preparation
for this project to do.
More on this next weekend

Ok a bit closer explanation whats currently going on (hiatus):

My day job is a bit demanding at the moment, so I reside to small tasks
wich are done in a limited timeframe and less energy consuming. For this
reason I did a lot of non programming stuff wich is partly related to the project,
(and partly not, but its ok, that way I have these projects out of the way wich
is always a good thing) and it shaves of some time for a slot I planed to use in september for programming.

So project related I work on seting up a few reference implementation of sIBLlight / lightsmith,
getting some infrastructutre for the test shoots etc. Also doing some minimal research on certain things.
All stuff wich would slow me down when I get back to programming mode.


Thats the plan, but things can always get into way.

not much done this week, just regenerating.

Anyway, note to myself since I just got a stupid idea for another method / idea to correlate
the light output besides a rudmentary radiance / watt / luxmeter correlation
of lights and hdri, with manual compensation (to get around the relative values of an hdri) ,wich I currently do:


Would it be possible to measure the output of the led panel (stage or simple background wich displays a certain section of the hdri)
via a luxmeter and correlate it with the previously measured values of the lights ?

So you use the LED output and correlate its luxmeter output with the sum of hdri pixels of that section displayed on the panel and then
use this a reference output for the lights / the brightness values of the hdri values at the light position.

So your LED background becomes the reference point to wich all other paramters (cam exposure / light max brightness)
have to be adjusted to. This somewhat makes sense, because those LED have the least leeway in brightness.


so the little detour in absolute hdri brightnesses has some payoff for this project

Ok, Idrafted out how hsl lights will beahve in both programs:

The (mental) problem I had was, that a HSL ligh coflicts with the channel defintons I have for RGB lights. Meaning I can't intermix the measured channel definitions with the dmx controls.
A Spectrum of a Hue channel does not make sense.

So I feared I had a bigger restructuring ahead in both programs splitting the dmx controls from the channel definitions. Wich was a major roadblock / mentally and worktime wise.
Not to mention that it would make both programs extra crowded.

A few weeks ago I realised thatr I don't need to... I can add the channel readout of the red green whatever color additionally to the HSL+ Controls channels but give it a DMX adress of -1

That way I can store as many channel definitions to the lightsmith file,
in sIBLstage I can extend the current (basic) color engine for hsl lights (wich doesn't derserve its name) to calculate the hue value with those -1 channels if they exist, and use the normal dmx channels for output. And switch to basic hsl control if the extra channels don't exist.

The downside is that it is harder to communicate it clearly to the user.
But again, this means lightsmithedit is almost finished, but I need a few weekends to polish things up, and a few weekdays to write the documentation / website.

sIBLstage stilll needs some weeks, but should go on smoothly

After some pause I have finaly started to work again on it.
Sorry for the delay, but since its a experimental hobby in my free time
it sometimes even gets set behind other projects.

Mainly bugfixes...the only noticeable behaviour change is that the light type
popup in lightsmith and internally in sIBLstage got drastically reduced to
none
mono
bicolor
rgb
hsv
not sure if none will exist until the first release. Originally I had the whole quick preset list of the Quick Add light functionality of sIBLstage in it...doesn't make sense.....in fact the whole popup does not make sense and should be done internally based on the channel defintions, but thats a thing after the first release.
Found still some small showstoppers in lightsmith...so sorry for the whole delay.

unsucessfull tried to add custom whitepoints in hsv mode:
Obviously the hsv transistion from a saturated color is not that easy to archive
(Lets say you have a new whitepoint at (h 0.1 s 0.1 v 1.0) and transistzion from blue
(h .0.6 s 1.ß v 1.0) you can not use a simple interpolation, since the hue would shift across half the spectrum the more desaturated it gets) Maybe if I convert it into rgb do the transistion there and convert it back into hsv ? Or use a different curve for the hue and saturation value so it only kicks in at high values ? who knows....

Maybe during workweeks my subconscious will find a solution for that, but for now I don't support it in the cogine, (But xou can still assign them in lightsmith fur a possible future usage)

ok, going the rgb mixing route is the way to go, but I still got some weird colors. But it might be a problem with the color engine of the light itself...still investigating

Edit: Mhmm...not sure...but anyway if no whitepoint is attached to it, the light falls back to its own color engine. Since those whitepoints can be edited deleted in sIBLstage file you can overide it from set to set.

- The overall luminance of a HSV light in lightsmith is defined in the intensity channel
  will be getting a dedicated panel for entering watts / lux and recalculate them into radiance
  (again its all about keeping consistent relative values of each light to each other)
- Added controls to the control channel, for a dmx offset in lightsmith.
So you can setup a default value when adding the light in sIBLsatge
(for setting the default mode of your light on loading).

Thats all for today.  Not making any promisses that I will return to it next weekend, depends how well
the lateshift will workout.

finaly got myself back tp coding

this weekend was about median cut.
This is a fun topic wich currently has 6 different "mthods" for automatic
position and coloring of the lights on the hdri. Here are some of the results:

Currently the method either prefers to put the lights in "spotty" positions
or provide a generic illumination of the environment.







for dark rooms the sIBL original median cut is the best to keep the spotty light sources


The lights are currently correlated from the area size of the cut and the lights definition
A correlation to the light output is planed, but not promissed.

So as long as I do not come up with a good method wich does both environment and spot in
one pass, I will provide those methods to quickly shift through, and make adjustments afterwards


Considering adjustments: the main view now has some similar functionality than sIBLedit,
meaning you can select a light for movement using  alt+leftclick and strg+leftclick
to move it without changing the light color.

and yes, a few bugs have been also squashed during this session

Just a few things to add to go on with a bigger reallife test. (Also to shoot some promo material)

Interesting, stumbled upon these guys:
https://cybergaffer.com/

cool to see others approach a similar "problem". they seem to be following a more static light rig approach, wich makes completely sense for
bigger studios wich do have permanet installed light fixtures. Also it seems more versatile in also supporting rt engines.
Using a mirror ball for calibration is also a nice idea.
Maybe this is could be also used to position the lights according to the hdri/ lighting information ?
Might be way better and reliable way than my idea of a smartphone position idea.

I really wish them all the best on this.

In the mail today (a bit of a comitment statement):




Yeah, terrible lights  and I actually wanted to describe indepth why I like
them despite their flaws. But to make it short, without them, I would not
be able to do this project. Maybe another day I make a review on them

I've got now 6 of these 200Watt RGWA lights, 1 rgb panel, plus 1 300Watt RGWA
Plus 2 BIcolor lights for this project (all dmx controleable)

I think that  is now close to the maximum amount of lights, small / mid scale
studios would be willing to invest and work with for such setups.
I might need to invest in a lightweight panel for overhead illumination
but thats not possible with my current budget for this project...maybe later

Ok, got some time for coding today and I was too tempted:
I wanted to know if its actually possible with little effort to get the liveview (hdmi>usb>cv webcam interface)
to display the transformed image of a mirror ball in realtime so you could do your light adjustments on the
fly with some feedback

This is just a prototype ui is gonna change


Vihy opengl you might ask and not a regular 2D Pano transform ?
Primarly I just need to transform the simple uv of a polygrid
to a mirror ball projection and let the gfx card do all the heavy lifting.

Also this setup might be usefull for future projects.

Still a lot to do....aspect ratio of the input video is still wrong, layouting, projection center, light overlay and north shift
but its a promissing interesting start.

Ok fixed all the issues I had with my previous post...video displaying the improvements
I made yesterday



Camera Selector and Aspect selector. Aspect has some presets to scale the
footage accordingly. Some work on the sphere picker to be more useable
(Position picking only inside the sphere

View is now flicker free, this will be expanded to the white balance
and another programming project.

OpenGL viewport
Now has a expand button so you can more clearly see the panorama when
positioning the lights
lights position of the SIBL are now displayed as an overlay. It respects
the north shift (This time the lights are shifted.
Overlay slider wich blends in the hdri (including its north shift)
Additive blending is also possible

Some work on median cut, imrpoved hdri readout and stability
(Did affect the general stabilty of the program)

Some quality of live stuff
Turn off Mouse Light Movement when certain functions are called (will be expanded)
If you select a light in the main view the light panel scrolls to the selected light

Next to do is channel editing in sIBLstage

not much done the last and this weekend, and propably not the next weekend.
daywork has currently a higher priority, and I do some more relaxing / braindead stuff
on the weekends. (My monday self will thank me for that)

Again a long time without anything to show, due to high demand at work.
I invested in another light, (a cheap lightweight rgbww panel) wich can be mounted on top of the scenery.
Ideally I would have invested into an amaran F22C but its outside my budget, and as I say that often
not having the ideal equipment works actually in favour of the project. I hope its light output is strong enough to simulate the sky color (minus the sun), but we will see.
Maybe I invest in an amaran if the release resonance is ok.

While I setup a lightsmith for the light I encountered some bugs wich have been fixed relatively fast.
(namely some save settings and some opengl display errors)

Lightsmith is now alpha, meaning I put everything in place so you could work with it. Its not very userfriendly yet, and it needs some tutorials to give you a starting point.  Also some failsaves have to be implmented: Checking if a whitepoint exists when the channel definitions have a dmx channel bigger or even than 0
Even the simple fact that you have a dmx channel of "0" needs some explaination.
Also some checks if a channel is assigned multiple times would be a good idea.



So whats next ? Actually its now time to get real and shoot some stuff. Will see how I can arrange a timeframe in the next few weekends for this. Then its about bug fixing the stuff I encounter during shoot and writing a premilary doc and a prerelease page on my main site. And since work is a bit of a fulltime job and I need some time for other stuff

So don't expect anything in may.