GH1 firmware research volunteers required

Fantastic thread & project - I donated some time ago but happy to go again if needs be.

I'l like to help is some way, I have 2 Pal GH1's (weddings) but I'm not ready to load any firmware - I'm up to my eyeballs in edits. (I check the progress during renders!)

If I can get an assistant to run tests / record footage on the unaltered GH1's - I'm happy to get that done - just let me know
 
I do not agree with you, I think the wiki would be useful. Currently using PTool is confusing to say the least, as one cannot be sure what the different hacks really do. That is one of the reasons this thread is so big. Noone wants to read all the 111 pages to find out what a certain item does, pros and cons, etc., therefore the very same questions are repeated again and again.

For instance there is the 1080/24p hack which is marked as (W) working. If someone does not rattle through the whole discussion they will not find out that indeed there is a downside: the camera won't play the recorded clips.

It would be much simpler if someone with the knowledge, power and time, who daily follows the thread put the most current situation on the wiki, then the rest of us would always know where we are standing.

I am not underrating tester13's work here, he does a great job, it is just that the tool is not too well documented.

What do you think?
 
This is graph of function (with all subroutines) that shows information or error messages
1273313339.jpg


It is much simpler than compression related things. :)
Used aiSee to visualise that. May be it'll be possible to make it WinGraph temporary replacement (they use same format).
But still no ability to specify depth and realtime filtering.
 
Last edited:
aczelkri said:
For instance there is the 1080/24p hack which is marked as (W) working. If someone does not rattle through the whole discussion they will not find out that indeed there is a downside: the camera won't play the recorded clips.

It would be much simpler if someone with the knowledge, power and time, who daily follows the thread put the most current situation on the wiki, then the rest of us would always know where we are standing.

I am not underrating tester13's work here, he does a great job, it is just that the tool is not too well documented.
Click to expand...

It is not well documented intentionally.
As we don't want many dummies at this stage.
Later versions will have special detailed help text for each patch.
But if you are concerned about this you can write description for each patch and I'll place it on first page already.
 
Further down the road it would be really nice to have after and before footage displayed side by side.
 
tester13 said:
What do you mean?
Click to expand...

I'm thinking he means 'before and after' shots:

original Gh-1 firmware/settings footage i.e. 1080p24 in a 60i stream

VS.

FW update (Final) 1080p24 native (without having to remove pulldown)

or

original bitrate VS. boosted bitrate etc, etc
 
alignment1 said:
I'm thinking he means 'before and after' shots:

original Gh-1 firmware/settings footage i.e. 1080p24 in a 60i stream
VS
FW update (Final) 1080p24 native (without having to remove pulldown)
Click to expand...

No one prevent him or any other guy to make such short clips and provide me links. I'll place them after each patch description on first page (links can be placed in help text in Ptool also, as it'll be HTML based).
 
Tester13, like you've said before many times it's too soon and last thing people should be doing is diverting the testers/developers' attention from this very important experiment...that is why I said "further down the road" :)
 
If someone want to get highest possible audio quality you could try 1.280.000 setting for encoding bitrate. Looks like it must work. Will be almost lossless.
 
rawfa said:
Tester13, like you've said before many times it's too soon and last thing people should be doing is diverting the testers/developers' attention from this very important experiment...that is why I said "further down the road" :)
Click to expand...

+1

As an ex-CEO of an software firm I know that the worst thing you can do to developers is to make them constantly explain and document each routine so that management can follow development progress and mess around with the code.
 
Documentation

Documentation

philiplipetz said:
+1

As an ex-CEO of an software firm I know that the worst thing you can do to developers is to make them constantly explain and document each routine so that management can follow development progress and mess around with the code.
Click to expand...


Having been involved in a number of software development projects (including being chief engineer for fly-by-wire flight control software for a real X-plane), lack of documentation is an impediment to extended collaboration. This project would go faster if more people were involved. What keeps more people from being involved? Lack of understanding of what the patches really do.

I think a lot more people would help in the testing effort if they understood what they were testing. I have a GH-1, but am not going to try patches that I do not even understand what effect they may have on my camera. If there was a clear description of what a patch does and what the desired tests are, then I would be willing to give it a shot. I think a lot of the people following this thread probably have this same opinion.

Documentation does not slow development, it speeds it up. As you said in your post, it is the management interference with code development that really bogs things down. But, don't blame that on the documentation.

Tester13 is clearly in charge of the code development for this project. I think the best help most of us can provide is in testing. What would help that is a clear definition of the tests to be performed and in what configuration. In my experience, this is helped greatly by a simple test spec. This may go something like:

Camera Model: NTSC or PAL
Original Firmware Version:
PTool Version:
Specific List of PTool patches to apply and the patch settings:
Video Codec for Test: AVCHD or MJPEG
Video Mode for Test: 720 or 1080
Frame Rate for Test:
Shutter Speed for Test:
Clip Length Desired:
Subject for Test: Test Chart or some particular scene
Motion for Test: Static Tripod Shot or Fast Camera Movement

There may be other items to add. If every set of tests is specified using this type of quick form, then people would know exactly how to perform the test. Then, when the results are posted, there would be no question as to how they were done or the usability. If we collected the test results in this manner then there would be a database to draw from and duplication of effort would be avoided. People could sign up to perform a particular test and others would know it is getting done.

That is my $0.02, but Tester13 should run this the way he chooses. I have an immense respect for what Tester13 is trying to achieve. I am not criticizing in any way the effort that has gone into this. I am only trying to suggest a smoother process for coordination of the effort so things can move faster.

Thank You!!!!
 
NPrincen said:
Having been involved in a number of software development projects (including being chief engineer for fly-by-wire flight control software for a real X-plane), lack of documentation is an impediment to extended collaboration. This project would go faster if more people were involved. What keeps more people from being involved? Lack of understanding of what the patches really do.

I think a lot more people would help in the testing effort if they understood what they were testing. I have a GH-1, but am not going to try patches that I do not even understand what effect they may have on my camera. If there was a clear description of what a patch does and what the desired tests are, then I would be willing to give it a shot. I think a lot of the people following this thread probably have this same opinion.

Documentation does not slow development, it speeds it up. As you said in your post, it is the management interference with code development that really bogs things down. But, don't blame that on the documentation.

Tester13 is clearly in charge of the code development for this project. I think the best help most of us can provide is in testing. What would help that is a clear definition of the tests to be performed and in what configuration. In my experience, this is helped greatly by a simple test spec. This may go something like:

Camera Model: NTSC or PAL
Original Firmware Version:
PTool Version:
Specific List of PTool patches to apply and the patch settings:
Video Codec for Test: AVCHD or MJPEG
Video Mode for Test: 720 or 1080
Frame Rate for Test:
Shutter Speed for Test:
Clip Length Desired:
Subject for Test: Test Chart or some particular scene
Motion for Test: Static Tripod Shot or Fast Camera Movement

There may be other items to add. If every set of tests is specified using this type of quick form, then people would know exactly how to perform the test. Then, when the results are posted, there would be no question as to how they were done or the usability. If we collected the test results in this manner then there would be a database to draw from and duplication of effort would be avoided. People could sign up to perform a particular test and others would know it is getting done.

That is my $0.02, but Tester13 should run this the way he chooses. I have an immense respect for what Tester13 is trying to achieve. I am not criticizing in any way the effort that has gone into this. I am only trying to suggest a smoother process for coordination of the effort so things can move faster.

Thank You!!!!
Click to expand...

I am not talking about best practices or documentation, I am talking about the distraction needed to make programming issues transparent to most people. My point is not to document, but to trust a core group to do it right. What we have not is not a collaboration but a single programmer (thank you!) and a bunch of ad hoc testers. The needs for this are different. I would rather he spend his time advancing rather than explaining. If he quits we will be in bad shape, but he may quit faster if we create time sinks. What we might consider is another person summarizing what seems to be happening. There are two types of documentation working and final. We do not need to move to final now.
 
Last edited:
philiplipetz said:
I am not talking about best practices or documentation, I am talking about the distraction needed to make programming issues transparent to most people. My point is not to document, but to trust a core group to do it right. What we have not is not a collaboration but a single programmer (thank you!) and a bunch of ad hoc testers. The needs for this are different. I would rather he spend his time advancing rather than explaining. If he quits we will be in bad shape, but he may quit faster if we create time sinks. What we might consider is another person summarizing what seems to be happening. There are two types of documentation working and final. We do not need to move to final now.
Click to expand...

I agree with this. Ironicallly, I also agree with the previous poster who mentioned lack of documentation being an impediment for collaboration. Sadly this isn't a well funded project with the usual structures in place to ensure that things get done and things get documented. What we have here is a maverick genius disassembling firmware without access (so far) to the hardware. One thing we shouldn't do is complain about documentation :). I don't see a problem with anyone setting up a wiki and documenting it, but it'll be an ever changing task during these pioneering times.
 
whomever set up the wiki site, should have members who've tested the patch PM him and he keeps the wiki site updated. nobody is taking the initiative to monitor the page. i would, or maybe i will if time permits. will post paypal balance today.
 
Guys, to be short.
I don't like this "documentation discussion". As I already said, you are free to make small and clear patches decriptions using HTML and even can provide links to video files (but not on rapidshare, etc).
Even better if you do something C++ related (see first page or my previous posts).

As for testing, we have already one request without actual testers:
"If someone want to get highest possible audio quality you could try 1.280.000 setting for encoding bitrate. "
I am interested if it actually works and how bitrate will be redistributed among audio and video.
 
Car3o said:
whomever set up the wiki site, should have members who've tested the patch PM him and he keeps the wiki site updated. nobody is taking the initiative to monitor the page. i would, or maybe i will if time permits. will post paypal balance today.
Click to expand...

And I am still waiting for tracking number on email. :violin:
 
You must log in or register to reply here.
Back
Top