Firmware Update for the AF100

[Rick Burnett]

My suggestion of course is for future cameras like the 250
I handle this isue on my af100 by lowering saturation and controling exposure. Sometimes it cant be helped

My question is why can't it be helped in post? There is no special magical digital code that can run in camera that cannot run out of camera in post. Any decision that happens in the camera with regards to limiting should theoretically be able to happen in post as well. There is still the issue of 8-bit and 4:2:0 but until someone actually implements a test to see how much those factors affect any algorithm to fix blow-out handling, we just don't know. Further, once something has been written to handle such things, I feel pretty confident that a few test shots with different blowout scenarios would give you the peace of mind in how the blowout would look in the future with such an algorithm. Every time I see the blowouts that people don't fix, they look the same to me.

I really wish I had the time to write a plugin for this because I would. It sounds like something that would be fun to test and implement.

Yes, I realize there is a render hit as well, I'm just saying since we don't have any in camera solution other than reducing saturation and controlling exposure, both of which I do as well, someone has the potential of making this and probably helping a LOT of people out.

If I do get some free time, I might throw something together in Max/MSP/Jitter as just an experiment to see what I can do (it's a visual programming language for video manipulation).

 

[PaPa]

The easiest thing i've found is just finding the chroma blowout color, moving the highlight wheel in the opposite direction gently and then lowering saturation slightly with a cruve in the high ends to help transition. Still though, not quite as soft as the DSLR. I am aware that they are two different beasts.

I would be very interested to see something like the GH2 sensor and codec, with the same OLPF and body as the AF100. Just a way to bridge the two worlds together.

 

[maxusa]

I would be very interested to see something like the GH2 sensor and codec...

Me thinks Panasonic will skip the GH2 engine in favor of the upcoming GH3 tentatively scheduled for introduction this year. I have a feeling that the new sensor will attack the dynamic range and low light performance in particular.

 

[Kenny_G]

Hacking any electronic device could cause damage. What if you shut off the heat monitoring code? What if you upped a bias voltage on something? Now, let's say you break your camera this way. Now let's say you put the old firmware back on and then ship it to Panasonic saying "It just stopped working." What if you ran someone elses code and you didn't know this is what happened, so you while you put the firmware back on, you send it back to Panasonic thinking that it was a manufacturing problem or something. These are the types of situations that companies try to avoid because they want to limit their possible costs in the future for things that are not their fault that they have a hard time detecting.

That's a feasable reason to protect the firmware i.e. the camera from hacking, but still what can we do to change something that need to be changed?

 

[Kenny_G]

That isn't what I said. I said that the AF100 was designed a certain way; it cannot change because of design decisions that were made 2+years ago. You can't change things that there is no path to. That is much different in tone that what you are saying. What you are saying is rather rude, implying that I was rude. I gave an explanation as to what it couldn't change, and your statement makes it sound like it won't change because we don't want to change it.

Moving forward and I mean future cameras not this one, I don't know how open the engineers will be on the camera design, but it is under study. The one thing that is the most difficult is controlling the path to key operational changes. This is a very dangerous path to leave open for anyone to walk though because with the right amount of hacking it could render the camera to be totally dysfunctional.

Best regards,

Jan

Sorry, very sorry Jan, it was not my intention to be rude to you. I love the way you react on this forum, but I hate the fact that we(I) have to accept that there is no solution for what we want. Keep on doing the good work!

 

[Shooter]

The person that will max this camera out to its potential ...will do it with skills and talent.

It will not be anything to do with firmware (or scene settings).

The problem with this camera (and others) is that it has opened itself to the "lesser skilled" through price point and promise, who believe that there is a "magic bullet" solution.

One day we will see something that truly sets the benchmark for this camera. (ie. No one will even consider what it was shot on ..and no one will care)

Think of your best film ever and then wonder if you care what the hardware was.

Meantime..go for it everytime.

 

[Paul F]

Of course, no camera vendor is going to open up their code. There is nothing in it for them. But the thought of being able to play ala Vitaliy Kiselev is intriguing.

 

[dcloud]

My question is why can't it be helped in post? There is no special magical digital code that can run in camera that cannot run out of camera in post. Any decision that happens in the camera with regards to limiting should theoretically be able to happen in post as well. There is still the issue of 8-bit and 4:2:0 but until someone actually implements a test to see how much those factors affect any algorithm to fix blow-out handling, we just don't know. Further, once something has been written to handle such things, I feel pretty confident that a few test shots with different blowout scenarios would give you the peace of mind in how the blowout would look in the future with such an algorithm. Every time I see the blowouts that people don't fix, they look the same to me.

I really wish I had the time to write a plugin for this because I would. It sounds like something that would be fun to test and implement.

Yes, I realize there is a render hit as well, I'm just saying since we don't have any in camera solution other than reducing saturation and controlling exposure, both of which I do as well, someone has the potential of making this and probably helping a LOT of people out.

If I do get some free time, I might throw something together in Max/MSP/Jitter as just an experiment to see what I can do (it's a visual programming language for video manipulation).

in post you could do what editman does, use a video limiter. im not sure whats the limit of that technique though but it does help.

 

[Jan_Crittenden]

Of course, no camera vendor is going to open up their code. There is nothing in it for them. But the thought of being able to play ala Vitaliy Kiselev is intriguing.

Please know that this sort of open code would never fly. What I am asking for is pathways where if the camera is hooked up to our computers the camera can be updated to do other things. It would never fly to have open source code for consumers to play with. That would be a warranty nightmare. It just needs pathways so things like what has been discussed here could be done and the only computer that can access that pathway is Panasonic's computer. I would never endorse having a hacker doorway. Having the ability to approach circuitry that is buried too deeply for the SD Card update yes, but only for the qualified servicer, but that could happen over the internet via PASS. And that is what I am asking for pathways to be built in and I haven't gotten Engineering's nod on it, but I am promoting the idea.

Best,

Jan

 

[reygun]

Of course, no camera vendor is going to open up their code. There is nothing in it for them. But the thought of being able to play ala Vitaliy Kiselev is intriguing.

but, as maxusa pointed out—it's playing (with the chance of breaking) a $480 body vs a $4,800 body. Applying hacks to my GH is great fun and wouldn't be a great lo$$, but am for one not looking forward to doing the same to my AF with the chance of completely being out of warranty and paying out of pocket to have it restored.

 

[maxusa]

As Jan wrote, she is lobbying engineering to develop a more robust system to allow for deeper firmware upgradeability. This is already present to a certain degree, but customers expect more substantial firmware updates along the product life cycle including enhancements. Call it anything you like (e.g., pathways), the centerpiece of the request is to push engineering to develop with higher robustness. And, subsequently, push engineering to dedicate additional resources for firmware maintenance after the product release. This increased scope would most definitely entail needing more engineering resources and/or time. What is being asked is to increase development cost and, therefore, lower profit margin on the premise of evolving market requirements. This is not a small feat. Asking anything beyond this change--like APIs or open source for 3rd party tinkering--is dubious and unrealistic IMHO.

 

[Paul F]

Thanks Jan, and I think we all clearly understood your message.

Keep the heat on Engineering. They hate product managers. Product managers keep asking for the impossible, but then after a while, Engineering comes around.