Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
WorkHorse
  • 227 Replies sorted by
  • @TrackZillas I think that the first second being low quality can be normal.

  • New GSpot, Boson and WorkHorse versions, 12 september 2014.

    Frame Buffer increased. Experimental stage.

    Complete details about versions in the txt file inside the zip.

    @driftwood we are in the need of a better tweaking in the frame buffer in these versions. The frame limits are already calculated. Can you give us some help?

    If you are willing to do some tests and measurements, please choose the setg version because it is the most stable I got until now.

    You said: "Just remember to test buffers with Elecard. You don't want them to overflow or underflow / or decline rapidly which will suggest problems."

    I am a newbie in Elecard, so don't know how to do yet...

    Thanks in advance.

    GSpot_Boson_WorkHorse_12_september_2014.zip
    599K
  • @frullaccia @TrackZillas

    always remember to format the card after firmware upgrade.

    after change pal/ntsc, turn camera off, remove battery, reboot the camera and format the card also.

    I got a camera freeze in a test, but after turn off, remove battery, reboot and format the same version did not freeze anymore, so remove batery, reboot and format are mandatory for stability.

  • I perceived an increase in image quality of boson flowmotion for details in last uploaded patches. it is working ok for details also. maybe it is due to the tweaked frame limits.

    gspot nebula is not showing improvements compared to boson nebula also.

    my new tests shows that both gspot flowmotion and gspot nebula can be abandoned.

    @frullaccia @TrackZillas

    for NTSC I did not test all setg from all versions yet, but some of them in 96Mbps setg versions I tested are working in the 12 september versions in my 45Mbps card. I think the frame buffer increase solved the problems. please try on your fast cards.

    if you want more datarate than 96Mbps for NTSC, maybe the 120Mbps setj is too much for 720p, try also 112 seti and 104 seth for 720p60.

    I strongly recomend to test all the 96Mbps setg PAL versions to perceive if there is one that will be stable. there are different gop tables, so probably one will be better than other. the 96mbps setg will be the best to test this in all versions.

    It seems that NTSC are ok in 12 september versions. I need your tests in fast cards to perceive if PAL versions are ok. try the 96Mbps setg from all versions in PAL.

  • some smart decisions are happening...

    if the image quality is already good, why increase the datarate? just to make it unstable? the goal is to get great quality and stability. one version loaded to camera needs to do the job, so I decided to tweak one datarate in the sweet spot for all versions.

    it is not good idea to shoot PAL in NTSC land or NTSC in PAL land due to artificial light flicker. So I decided to tweak PAL and NTSC separately for best improvement on both.

    less versions, less tests, sweet spot in quality with more chances to get stability.

    and avoid the final user to keep changing different firmwares.

    will upload.

  • The versions 12 september 2014 uploaded in previous post are already OK for NTSC, just the gspot versions are no good.

    the 104, 112 and 120 versions improves datarate for 720p60 and makes the boson great for details also. I tested one 120mbps version in the 45Mbps card and it does not freeze the camera. 112mbps seems to be sweet spot for ntsc for great 720p60 quality.

    in 112 and 120 versions the boson reaches the good details quality, so no need to use workhorse.

    the 120Mbps versions shows 86Mbps in 720p60 ntsc in streamparser, this was the impossible goal, and it is working.

    there is no need of more tweaking for NTSC

    my tests are showing that for pal I just need to increase the frame limit and it will be done.

  • @apefos @TrackZillas I tested the Pal 96Mbps versions. It was early morning and foggy, the light was changing fast. I can't say very much about quality. FSH and H look pretty good. These clips show some horizontal line in critical areas (grey-white, foggy sky). I had a problem with Workhorse-Nebula. I couldn't record in 720-50, because the camera stopped (this was the first test). 24 and Hbr are ok.

  • I didn't try the gspot set.

  • @apefos @TrackZillas Giving a second look to the clips, I can see some horizontal line in the Flowmotion 24-Hbr set. Testing boson-nebula I had the best, impressive HBR clip (the Nebula 24H is less appealing, and during this test with Boson the picture was a little noisy-flickering). Consider that this was a hard test for the camera (zooming, moving fast, focusing in a white sky at early morning).

  • @apefos @TrackZillas Second test. Workh Flowm 96Mbps not working in fsh and h mode. Than a fast comparative test between Boson Nebula 120 and the 11 september version of Workhorse Flowmotion. While the last works in FSH and H mode, the Boson Nebula doesn't. I also must say that the picture quality of 24andHbr in WF 11sept is much better than the BN 12sept, despite some horizontal line crossing the white sky. This is what I saw with my pc.

  • there is a problem in the nebula. the original nebula does not have fallback tables. this makes the frames size to vary so much along the frames flux. this variation makes it more unstable because when the frames gets so high in some moments even in a static scene, and there are chances of reaching the frame limit and also increase datarate suddenly. this can make the camera stop recording or freeze. i did different attempts to solve this repeating the I, P and B tables in the fallback and also using the flowmotion fallback into nebula. the flux got more stable, but two problems happened: with the flowmotion fallback into nebula the frames flux got more homogeneous, but sometimes some frames jumps high, because the flowmotion fallback are not made for work with nebula. repeating the nebula I, P and B tables into fallback makes the flux continous but makes some pulsing in image to happens in high iso. there is the need of building three custom fallback tables specific for nebula, for 24p, hbr and 720p. this is very difficult to do, needs lots of learning about matrix and lots of try error attempts. beyond my knowledge and working time. it is a task for @driftwood to do.

    in the nebula the tables for I, P and B are different values, so the fallback table cannot hold the I, P, and B frames size simultaneously. I did also a try to repeat the same tables in I, P and B to make the fallback holds I, P and B sizes simultaneously, but also got the pulsing in image. even repeating the same tables in I, P and B there is the need to build a custom fallback table for nebula.

    the nebula has a very fine grain/noise, it is beautiful, but this problem makes it impossible for me to finish the tweaking.

    I will concentrate my efforts to finish the flowmotion because there are much more chances to get great quality and stability. the fallback tables in flowmotion are very well done by @LPowell

  • Boson - WorkHorse - 13 september 2014

    (see in post below same versions including gspot)

    Boson_WorkHorse_13_september_2014.zip
    399K
  • @apefos Tested in a sunny afternoon the last two settings of Workhorse Flowmotion Pal version. 120 freezes in fsh and h mode. 112 works perfectly (fsh and h mode are exceptional; also 24h and hbr are wonderful). I made a fast comparison between three versions of WF120 (10, 11 and 13 sept.). Quality is almost the same. Maybe, but I can't be sure, some slight improvement in this last version (a better stabilization of the picture during hard camera shaky movements, zoom, and so on... It's just an impression). Well...

  • @frullaccia so it seems that it is done! please try 720p50 SH and H PAL, the most difficult modes. if 112 does not work, try 104 and 96 in 720p50 SH and H PAL, this report is very important.

  • @frullaccia the image in this version last has the most stable noise, grain, and cmos sensor pattern.

  • Boson - WorkHorse - 13 september 2014 (with gspot for ntsc)

    • separate versions for NTSC and PAL
    • choose from setA to setJ according to card speed
    • from setA to setJ datarate increases from 48Mbps to 120Mbps in 8Mbps steps
    • now the datarate in 720p60 ntsc can go above 80Mbps in the video file
    • datarate 84Mbps in 720p60 NTSC is similar quality to 70Mbps in 720p50 PAL (1.2x ratio)
    • datarate in video file is different from the values typed in the ini file, this is normal
    • developed in PTool v3.65d
    • boson improved for better noise and textures in 720p
    • workhorse improved for better details in 720p
    • this difference turns less noticeable in versions 104Mbps and above
    • this difference is more significantly in NTSC versions
    • gspot versions specially developed for NTSC with best balance between boson and workhorse
    • pal versions does not need gspot because less fps means more data per frame
    • in 720p60 ntsc the H slot can show different saturation than SH slot in low light, compare them
    • versions 104Mbps and above can be unstable in PAL versions
    • all versions have the flowmotion scalling tables and deblocking tables
    • use the 5DtoRGB free software to convert the MTS files to ProRes before edit, this avoids the diagonal noise patern (rain)
    • feedbacks and reports welcome, show your videos on vimeo, youtube, and original mts files
    Boson_WorkHorse_13_september_2014_GSpot.zip
    501K
  • @apefos @frullaccia going to do some testing today was busy shooting yesterday. Which patch should I try the September 13 one? Apefos got one question how come you don't develop them in PTools v3.66?

  • @TrackZillas @frullaccia yes, try the september 13 with gspot included, the last uploaded, most updated and stable, including last tweaking in matrix, datarate, frame limit, frame buffer, best image quality. working ok for me.

    please, don't forget to try 720p50 PAL and 720p60 NTSC, SH and H, the most difficult modes for stability. hbr comes after. 24p is more easy for stability.

    remember that I cannot test the 104, 112 and 120Mbps versions, my 45Mbps card does not allow me to do... I got some seconds recording with these versions, enough for tweaking the patches, but the full stability is in the need of your tests with the fast cards above 80Mbps write speed...

    about PTool: I just don't know... things are working ok with the PTool 3.65d, I was supposing the 3.66 is beta and 3.65 is stable... I am used to deal with the 3.65, I will take a look into the 3.66

    would be good idea to upload some short original MTS files (7 seconds recording are enough)...

    this pic is for inspire you in your tests and shoots:

    patches.jpg
    1280 x 721 - 250K
  • I only tested Pal settings with a Lexar 90Mbps card, because I saw before that Ntsc settings are stable. I tried boson 104, where all modes were ok. I had an excellent H mode clip. Then I tried the boson 112 set, where the camera couldn't record in SH, while it made a stable recording in H mode. The Workhorse 120 datarate set is the best performing in 24 and HBR mode (it doesn't work in SH and H). Finally, I tried again the 12th september Nebula 120 in HBR mode (pretty unstable). The camera stopped two times. In the end I've got a very beautiful and interesting picture. For people who has got a Sundisk 95Mbps could be useful a Workhorse datarate set of 128 or 136, just even to try them. They could be working on it.

  • @frullaccia thanks, it seems you found your best PAL version. the 24p datarate can be increased, but 720p cannot, you already found the maximum 720p datarate for your card. to my eyes 96Mbps for 24p is more than enough... but you can merge 24p settings form one ini file with 720p settings from another and test.

    my advicce for PAL people is to try the 96Mbps setg because 720p50 datarate on it is more than enough also.

    I believe if there is no posts it is because things are working now in last versions.

    I got an idea of testing gop4 in ntsc 720p, in an attempt to improve the p and p frames size without increase the datarate.

    my 45Mbps card works ok with the setg 96Mbps ntsc patches and no problem, to use higher datarate i need a new card, so I got this idea of using gop4 in 720p ntsc...

    another interesting idea is to try gop2 in 720p50 PAL...

    I am also doing tests to finetune the gspot even more...

  • @apefos Thank you! I think you can take it easy now and just have fun with your alchemical production. To have got a limited datarate card could have been a sort of a challenge to achieve better results. Limitation fires creativity.

    In any case a tweaking at 128 or 136 is worthy a try, because quality gets higher. I know that you said 96Mbps is enough. Well... Are you sure?

  • @frullaccia I reduced the developing speed. things got more mature now, if I do more tests it does not need to be in a hurry. i feel better now, some peace.

    the 45Mbps card was helpful. it is a great coincidence: this card is in the limit for the 720p60 ntsc datarate. the boson and gspot was born due to this card.

    about datarate, when I tested the 112 version, the camera did not record more than 96Mbps in a low light, low contrast shoot, so I perceived that 96 for low light is enough in 24p. some time ago, without custom tables, just increasing datarate, the ini file was at 128 gop3 but the camera did not record more than 114 in a good light low iso scene in 24p. so if you use the setG or setH version and raise the 24p to 120 or 128 and keep the 720p as is to get stability, you will get the best from the camera.

    @TrackZillas did I scared you asking for lots of tests? no need to do so much, just some words in a feedback about stability is ok!. I did a look in the change history of ptool 3.66

  • about compression:

    for 720p:

    in my tests to develop the gspot for 720p60 ntsc I perceived that 9.5:1 ratio is the limit for compression in h264. at this compression level in gop3 IPP, the I frame is in the lower limit to keep good details and the P frames are in the lower limit to keep good texture and noise. in the gop3 the I frames cannot have a compression higher than 5.75:1 or 6:1 maximum. and (P+P) / 2 must be at around 14:1 compression ratio maximum. I found these limits looking close to the full hd screen when I see the death charts shoots and low light shoots. and then I developed the gspot for ntsc keeping the frames at these sizes in the GSpot setG 96Mbps version which I keep in my GH2 to use with the 45MBps card.

    70Mbps in the video file for 720p ntsc gop3 gspot is the lower limit for great quality.

    PAL 720p has 20% less frames than NTSC so datarate can be 20% lower. 58Mbps in the video file for 720p PAL is the lower limit.

    for 24p:

    96Mbps in 24p is around 6:1 compression ratio, pretty good. remember that this is the overall compression, the I frames compression is lower and the P / B frames compression is bigger. similar limits of 720p compression ratios limits for i / p / b works here also.

    120Mbps 24p will be at 5:1 compression ratio, considered the sweet spot by the RED users. RED users even shoot at 7:1 and 8:1 for cinema which they consider ok, 10:1 in the extreme limit. in the last uploaded patches the setG ntsc versions and the setE pal versions are inside these limits for 720p

  • @apefos My previously early morning tests affected by zebra stripes has to do with this: http://www.personal-view.com/talks/discussion/6094/diagonal-rain-appears-using-gh2-premiere-pro-cs6-without-a-hack/p5 Due to low light I was truly shooting at 800 iso.

  • @apefos A sample at 112Mbps, HBR Pal mode. Full zoom, stabilizer, afs. Hands trembling on purpose.

    http://www.filedropper.com/00000_3