BTM_Pix

It tells the app from the camera which menus to offer to the user. By mimicking the camera side to the app, it might be possible to persuade it to show them but it would only allow the same commands that have been sent directly from the browser to be sent by the app so the end result will be the same if the camera doesn't fancy it. And it would be a lot of work to write something that mimicked the camera as the computer would have to act like a server amongst other things and because of the stay alive heartbeat between the app and the camera it would require effort that I fully expect would only prove what is already known. Which is that if the camera itself doesn't have the recipe or the ingredients to make a cheeseburger it will just not make a cheeseburger however nicely we ask.
Everyone is of course welcome to try that but I'm going to focus in another direction as I firmly believe that using this method will not bring additional formats and if it does then you are into another layer of additional work to create an app to massage the metadata and there will always be the limitation of no in camera playback.
The only nagging thing I have about it that might be worth trying is to set the region using the octopus boot up method to Japan. It is in no way guaranteed or expected but neither is it beyond the bounds of possibility that for its own domestic market, Panasonic may have additional functionality. 
 
------------------------------
 
When the cameras return a rejected message rather than an err_parameter it is usually indicative of it not being open for any sort of burger business, cheese or otherwise.
There are usually two scenarios for this.
1) The ImageApp is also running.
2) The camera is in a menu.
And number 3 is likely to be the one that is being seen here which is that it is utterly confused about the burger that you've just asked it to make, has set the kitchen on fire and the order window has been automatically closed by the sprinkler system.
If it could, it would be displaying this image on its rear screen 
 

What I think might be interesting is if you deliberately drive it to the boundary of where there are cracks between the positions, so between 101 and 120 for example on the 14-42 there is a nice bit of space to work in.
If you drive it to 120 and then give it one more tele_slow command and see if it goes to 119 or does it go directly down to its next boundary point of 101.
Similarly if you drive it deliberately into the cracks with a tele_fast or tele_slow will it sit at that point or round itself up or down.
For stills I can see an issue with falling into the cracks depending on your interval but I think in terms of motion for a fader that a user wants to go from position A at the top of the throw to position B at the bottom under manual control then there might be more latitude to get away with it. 
I think that the lenses themselves optically might be a bigger hurdle to a really nice pull (especially with the breathing and the unknown sneaky correctional stuff that often foes on under the hood with these cameras) than the process.
Well, that'll be my excuse anyway

Anyone guess what might be going on here then?
 

Thanks
To be honest, the accuracy of the lens control and what you can do with it is always going to be varying degrees of fudge without the command to directly return it to one of the 0-1024 positions.
I presume by profiling for focus steps you're referring to how many actual focus positions there are hiding within the 0-1024 range?
With some of the lenses it feels like there are only about 6!
I don't have a big range of native MFT lenses (and all of them are the cheap ones!) but I was wondering if requesting a dump from them using http://192.168.54.1/cam.cgi?mode=getinfo&type=lens might offer up an automated answer to what you're after.
This is the output for what its worth
 
Olympus 45 1.8
ok,2304/256,434/256,3584/256,1195/256,0,off,45,45,on,128/1024,on
 
Panasonic 20 1.7
ok,2048/256,392/256,3584/256,1195/256,0,off,20,20,on,128/1024,on
 
Panasonic 12-32 3.5 5.6
12 
ok,2304/256,925/256,3584/256,1195/256,0,off,32,12,on,128/1024,on
18
ok,2304/256,1062/256,3584/256,1195/256,0,off,32,12,on,128/1024,on
32
ok,2304/256,1273/256,3584/256,1195/256,0,off,32,12,on,128/1024,on
 
Panasonic 14 2.5
ok,2304/256,677/256,3584/256,1195/256,0,off,14,14,on,128/1024,on
 
Panasonic 45-200 4.5 5.6
@45
ok,2304/256,1024/256,3584/256,1195/256,0,off,200,45,on,128/1024,on
@100
ok,2304/256,1138/256,3584/256,1195/256,0,off,200,45,on,128/1024,on
@200
ok,2304/256,1273/256,3584/256,1195/256,0,off,200,45,on,128/1024,on
I can make a guesstimate of what each of those parameters are (and you can see that the third one x/256 is current focal length as it varies within the zoom etc) and unfortunately the answer you're after isn't in there. 
Obviously, if you manually put the lens at infinity and try and nudge it one more place with http://192.168.54.1/cam.cgi?mode=camctrl&type=focus&value=tele-normal
It will return
ok,0,1024
So you know that its correctly hit 0 and similarly if you put it at minimum distance and tell it go one step wider it will return
ok,1024,1024
And that obviously doesn't change per lens so at least thats consistent!
In terms of creating something functional from what we have to play with, whilst it would be desirable to hit exact points, the four focus functions that we have at our disposal can be massaged into doing something useful using methods like your comparison routine to return to a specific point.
The key to making it a useful practical function though is being in control of the entire process.
If we are driving the focus ourselves using a stick or fader then we have constant feedback of which of the 0-1024 values it is currently at so this can make the profiling unnecessary as we always know this is a 'legal' value because the user has chosen it based on the image being in focus therefore it must be an actual focus point the lens is capable of. And if we now that then, of course, we should be able to make it return to it.
The transition between two such points is something that, again, if we are in charge of the whole process - i.e. the user has focused using our focus controller and will be doing a physical pull from A to B with our controller (particularly a fader with fixed end points) - then we can scale it to at least make it a consistent experience. By consistent I mean, the rate at which they move the fader from one end to the other is controlling the rate of transition irrespective of how many or few actual focus points the lens is capable of resolving. Don't get me wrong, it will always be a fudge of sorts but if we are up against the limitations of the lens in terms of how coarse the transition is then it would be like that anyway if they did it manually. 
The proof is in the testing I suppose to see how smooth or not it is with each lens (and I'm not ignoring some inherent glitchiness caused by the way we're communicating with the camera either) and then the challenge is to try and mitigate it and smooth it out with different scaling techniques.

Thanks for your reply.  I also have a Pi so looking forward to when you give the information on this, great work

I want to share a short script I wrote in python that does focus ramping time lapses for Panasonic cameras. I believe this is doable in magic lantern for Canon users but I've yet to see an implementation for Panasonic. Here is a short technical preview:
Here is the python script I used to make this focus rack timelapse:
https://github.com/lippyt/lumixlib/blob/master/focuslapse.py
I'm sure that there are much more creative uses especially for shots with the majority of objects in the near-medium range.
 

A focus slider and and switches for sensitivity settings of the slider would be great.

Hi BTM_Pix, love your work with the focus controller!
Would you be doing lens profiling/setup for lenses for this focus racking system? I've done some minor research into how many possible focus steps there are per lens and I found that it varies between lenses and even among different focal lengths on the same zoom lens.
I would believe this will affect the duration of a focus pull depending on how the focus racking code is done.
If you've already considered this, perhaps we could request fellow forumers to share their lens focus step data so that there is a more complete picture as to how focus step varies.
Here is the python file that I wrote for finding lens data: https://github.com/lippyt/lumixlib/blob/master/lensdata.py

Yes, all simultaneously. 
I'll sort a video of it in operation later on.
Curves are still under development....

This way cool!

The very first prototype I did was not too dissimilar actually !

Its highly likely that it will be purely dependent on what controller people want to use.
Its fundamentally in there but just mapped to a thumbstick at the moment. A controller with a fader in (or many faders) is easily supported.
Watch this space, I suppose.

Anyone guess what might be going on here then?
 

Yes
And yes again.
Its for live interactive control of the profile, sharpness, noise reduction, saturation, hue and ISO to create new custom profiles.
Amazingly enough, it actually work as well!
Even more surprising is that it allows this while you are recording.

Yes
And yes again.
Its for live interactive control of the profile, sharpness, noise reduction, saturation, hue and ISO to create new custom profiles.
Amazingly enough, it actually work as well!
Even more surprising is that it allows this while you are recording.

Yes
And yes again.
Its for live interactive control of the profile, sharpness, noise reduction, saturation, hue and ISO to create new custom profiles.
Amazingly enough, it actually work as well!
Even more surprising is that it allows this while you are recording.

I am currently checking out two controllers to use with it that I think will be the definitive ones for people to choose.
There'll be an update with them next week so stay tuned ! 

Yes
And yes again.
Its for live interactive control of the profile, sharpness, noise reduction, saturation, hue and ISO to create new custom profiles.
Amazingly enough, it actually work as well!
Even more surprising is that it allows this while you are recording.

Am still working on my film and still loving the results. Here's a screengrab from my shoot yesterday. I just threw a LUT on there, to get it into Rec709. I'm sure the final look will be different and more refined...
 

However I do have a question for some of the ML Raw veterans out there... I tend to shoot a lot of silhouettes, and I am finding it tough exposing for them. The Raw histogram is telling me it is overexposed when the sun is in the shot, so when I close the Iris to get me some sun stars, even though it is still showing as over exposed, I am getting a crap ton of noise. I know @squig ends up with some dark footage, any ideas?
Also any new news in 3K/4K Raw?

The very first prototype I did was not too dissimilar actually !

Anyone guess what might be going on here then?
 

Anyone guess what might be going on here then?
 

Anyone guess what might be going on here then?
 

This is how some future archeologist will find me, with the loop of incremental parameter changes still merrily being fired at a Panasonic G7 in the background.
 

One of those where we don't like what we see on a histogram but we do like what we see in the actual image.
There's a moral in there somewhere...

I can't give you the definitive answer regarding the exact combination you're after but I've got an 8mm Samyang that I've put on a Nikon D800 to do a quick test for you.
The D800 is obviously full frame but does auto crop at 1.2 and 1.5 so these examples show you exactly what it covers at full frame, 1.2 and 1.5
Judging by that, I'd say you'll probably get away with it.
Maybe