Jump to content

Stathman

Members
  • Posts

    120
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Stathman reacted to MrSMW in Panasonic S5 Entry Level Full Frame seems to be real...   
    Kaboom, it's arrived!
    Sorry, no YouTube unboxing video or reading of spec list, just an initial impression whilst the battery is charging.
    I've come from 8-9 years of Fuji as my main cameras with some dabbling in 1" Sony and M4/3 Panasonic but have otherwise never owned a full frame mirrorless before.
    I had Nikon DSLR prior to Fuji for stills with a D7000 for filming...but things have moved on since 2010!
    First of all, it feels superb in the hand. In terms of size for handling and my use, just about perfect.
    Weight, perfect and I currently have the 20-60mm 'kit' lens attached I bought it with which will become my personal travel lens and my stills work wide angle.
    Build quality. Well all my old gear has now been sold but I'd say it's all a step up from Fuji and I had no complaints about that, but the build and finish are superb and the way the dials click and operate etc.
    Next up, some stills and video tests to get a feel for how it all works etc and that all important AF test..., but so far, it's all looking good!
  2. Like
    Stathman got a reaction from IronFilm in Fuji X-H1. IBIS, Phase Detect 4K beast?   
    Firmware 2.10 available.
    https://fujifilm-x.com/global/support/download/firmware/cameras/x-h1/
    Auto exposure stepping issue fixed. (Auto ISO video mode).
    I can definitely see an improvement on ibis stepping issue too.
    Well done!
     
  3. Thanks
    Stathman reacted to dgvro in Fuji X-T4   
    I've used the XH1 and now own an XT4.
    The XT4 is definitely just... better when it comes to IBIS. I found the XH1 to be sickeningly bad for the way I shoot, I had to get rid of it asap. Those little quantised jumps in sensor movement were destroying shot after shot. The XT4 has similar but more well-controlled issues I suppose. It's not up there with Panasonic IBIS though (not like GH5 anyway).
     
    You're right about the planes of movement thing, this is the key with Fuji IBIS I guess. It just can't handle any sort of movement in more than one plane at a time. Tilt while panning? You'll get tiny jerks and catch-up movements in the stabilisation. Likewise strafing or raising the position of the whole camera in space while panning or tilting. You have to be very deliberate with the XT4 handheld movements. I never use the DIS digital stab. The IS Boost seems to be okay, to be honest I can't tell the difference in what that's doing half the time. It's performance may have been altered a bit in one of the firmware updates and I'm just confused about its efficacy now at this point.
    Something about the XT4 footage stabilises pretty nicely in post, thankfully. Maybe the good performance for rolling shutter is important there. Stick (in DaVinci Resolve anyway) to the straightforward 'translation' type stabilisation and you can avoid the dreaded "warpy shit". So if you're happy enough to polish your footage after that way, you'll get perfectly great results with the XT4 IBIS, yes. Especially with a heavier setup, I guess.
    The codecs are really great. I'm delighted with how well they hold up in terms of noise and dynamic range. They playback/edit fairly well for h265 and all too on my laptop.
  4. Like
    Stathman reacted to Andrew Reid in DXOMark mobile camera rankings corrected   
    Here's what the 10x zoom (18-240mm) looks like on the P40 Pro Plus.
    18mm

    28mm

    80mm

    135mm

    240mm

  5. Like
  6. Like
    Stathman reacted to Andrew Reid in The EOSHD Interview - Kazuto Yamaki, CEO of Sigma and Takuma Wakamatsu, Sigma Fp Product Manager   
    I'd like to welcome Kazuto Yamaki, CEO of Sigma and the product manager of the Sigma Fp and Cinema lenses, Takuma Wakamatsu to the pages of EOSHD for this long interview!
    I have recently been shooting with anamorphic with my Sigma Fp - the video you can see above is shot with the Rapido Technologies FVD-16A focus module housing a tiny Bolex Moller 8/19 anamorphic. I have more on this soon, as well as how ProRes RAW performs on the Sigma Fp attached to Atomos Ninja V.
    Ever since the Sigma embarked on the high quality ART lenses the company's factory has output higher and higher quality products, even industry leading lenses in fact. Now the Sigma Fp marks their entry into filmmaking cameras too with internal 4K RAW recording, external ProRes RAW and even BRAW - as well as being the smallest interchangeable lens full frame camera available on the market.
    Read the full interview:
    https://www.eoshd.com/news/the-eoshd-interview-kazuto-yamaki-ceo-of-sigma-and-takuma-wakamatsu-sigma-fp-product-manager/
  7. Thanks
    Stathman got a reaction from andrgl in Inspecting the Fuji GFX 100, and having a cup of tea   
    Atomos Enables 12-bit 4K ProRes RAW Recording with Fujifilm GFX100 via Firmware Update!
    https://www.atomos.com/firmware/ninja-v#TWfullr-FujiGFX100
     
  8. Like
    Stathman reacted to Andrew Reid in My Canon EOS R5 recording 8K video 50 minutes straight   
    Thanks for the chart. It's good to have it in black and white that there's only a 6-8C increase in temps after 20 minutes.
    Certainly not enough to justify the shutdown (let alone a long lockout).
    And also interesting to see the temps are basically flat for the last 50 minutes after the first 50 minutes.
    I think if we are going to put credits on stuff by the way, make sure to include @BTM_Pix
    His app has been key to understanding the temperature status and EXIF temp.

  9. Thanks
    Stathman reacted to Electroholic Anonymous in My Canon EOS R5 recording 8K video 50 minutes straight   
    My R5 survived the 1 hour and 45 minute 8K IPB SD FAT32 recording test! Peaking at 62C exif from the end of the 3rd run to the end of the 6th run. Will the FW update allow us to run 8K IPB for more or less than 100 minutes at a time? I will present the exif temps shortly and send the data to Horshack.
  10. Like
    Stathman reacted to horshack in Canon EOS R5 so-called overheat timer defeated by a single screw in battery door   
    Just tried it for a longer video, this time 10:00, to test two splits and it still works. Two perfectly-good .MP4 files, each approx 4GB and 4:41 in length, and an RP with amnesia after powering it back on.
    The only limitation of this technique is 32GB, since Canon cameras format all cards > 32GB as exFAT, even though FAT32 supports volumes up to 2TB. But there's a workaround for that as well - format the >32GB card on computer instead. Windows 7/10 wont let you format cards > 32GB to FAT32 but there are third-party utilities that will. I just used http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm on a 64GB card and the camera accepted the card with no complaints. Recording to it right now on my RP to test splits for a very long video. And while Windows wont let you format >32GB cards to FAT32 it will mount them just fine.
  11. Like
    Stathman reacted to horshack in Canon EOS R5 so-called overheat timer defeated by a single screw in battery door   
    You sir win the internet today. I just tried it on my Canon RP, which like the R5 forgets any changes to the camera's settings (like exposure settings) if you pull the battery in the middle of the recording but will remember the changed settings if you stop a recording normally.
    Procedure:
    Tape down the door sensor and leave the door open so the battery is accessible Put a 32GB card in the camera and Turn the camera on and format the card. It will automatically use FAT32 cards with a capacity <= 32GB Start a video recording, in this case I used 4K 24P, which has an average total video/audio bitrate of 14.43 MB/s. Shoot a video whose length will exceed 4GB. For my 4K 24P that's any video longer than just under 5:00. I shot one for exactly 5:00 Pull the battery Check the card and verify there's a single .MP4 file Reinsert the battery and verify the camera "forgot" the previous session's settings We know the camera saves its settings whenever it has successfully recorded a video. The question is whether @Jn- idea will avoid that save for the FAT32-case of splitting up a video file at 4GB/each (FAT32 limit), provided we still pull the battery at the end of the recording. In other words, will the camera save NVRAM for each intermediate 4GB-split file or only for the final file after properly stopping a recording?
    Drumroll...It works! My RP's aperture was f/4 when I turned it on for step #3. I changed it to f/11 for the test. After reinserting the battery my RP's aperture reverted back to f/4!
    Andrew, please test this ASAP on your R5 and see if it matches my RP's behavior of forgetting the settings, the most important of which is of course the thermal timer.
     
  12. Thanks
    Stathman reacted to horshack in Canon EOS R5 so-called overheat timer defeated by a single screw in battery door   
    Made a lot of progress on understanding the .DAT files. Using my Canon RP as a test bed, I recorded two 1:00 videos, one regularly and the other power-interrupted. I then copied the entire SD card for each case as a file image to my system for analysis. Prior to recording video each SD was prepared by fully wiping it with dd, then formatting in the camera. I also went back to FAT32 because it's easier to analyze those structures than exFAT.
    This yields two very similar filesystem images. For the regularly-recorded video SD image I see a single data file (MVI_0478.MP4 in this specific case). However if I analyze the directory entries in the FAT32 structure I see a second file that's been deleted, named ?VI_047.DAT. The '?' is there because the file has been deleted (0xE5 is the FAT32 marker to indicate a deleted directory entry), meaning its original name is MVI_0478.DAT. Even though MVI_0478.DAT has been deleted its FAT32 cluster location and most-recent file size is still available in the directory entry.
    Looking at the contents of the .DAT I see an "mdat" field. This is the raw MP4 data holding the video/data of the video - it's called an "mdat atom" in MP4 container parlance. The size of the .DAT file is exactly 128KB less than the size of the .MP4. What's more, the on-SD location of the .DAT is exactly 128KB after the .MP4, which means the two files are actually contiguous with each other.
    So the camera wrote the .DAT first (while recording the video) but left 128KB before it pre-allocated in the FAT32 cluster table. When the video recording stopped it then wrote the 128KB before the .DAT, which contains all the other MP4 atoms necessary to represent the file, including the 'moov atom' which was reported missing when trying to recover the .DAT as .MP4 earlier using open-source recovery tools (failed because it's missing the full 128KB .MP4 header).
    The 128KB MP4 container header stuff + mdat atom content represents the full MP4 file.
    So the .DAT files we're seeing for the interrupted recordings on the R5 are the actual raw video/audio data sans the proper 128KB MP4 header area.
    On my Canon RP the .DAT directory entry is missing for the interrupt recording. However if I go to the location on the interrupted-SD image as where the .DAT file exists on the good-SD image I see the mdat data. So it appears that on my RP the camera writes to this area during recording without first setting the directory entry to reflect that area is allocated. If you're able to see the .DAT files from your 1DX that means the behavior of that camera is different. Not sure how the R5 acts. Either way, recovering the .DAT file for my RP is trivial because I know what cluster it begins on by comparing it to the good-SD image.
    I found the .DAT area on the interrupted-SD image and spliced in the 128KB MP4 header from the .MP4 from the good image. The file plays...and I hear a quick snippet of sound, but no video. So there is work to do there. But at least it demonstrates the basic integrity of the full MP4 is in place.
    To get this working on R5 images we'd have to determine how to build the proper 128KB MP4 container header, the same as how the camera builds it when the user ends a video recording. This might be as simple as splicing from a "good" .MP4 image, but probably requires a lot more effort, and then graft that 128KB header data with the the .DAT file to reconstruct the full .MP4
  13. Thanks
  14. Thanks
    Stathman reacted to Andrew Reid in Removing internal battery resets EOS R5 overheat timer   
    We tried this via the Wifi App by @BTM_Pix
    It just changes the data and time, it does not reset the separate clock used to measure the camera up-time.
    I can confirm Magic Lantern are looking into it.
  15. Like
    Stathman reacted to BTM_Pix in Removing internal battery resets EOS R5 overheat timer   
    Remember this ?

    So, again, I find myself thinking that tonight's tweet is a very funny way to spell "Boy we were wrong about this and our sincerest apologies to Andrew for trying to incite you all to pour scorn on him when he raised this on day one".
    Shameless.
     
     
  16. Thanks
    Stathman reacted to Andrew Reid in Removing internal battery resets EOS R5 overheat timer   
    "Math Class" on Baidu now has extensive infrared thermometer readings of the camera's mainboard with the back off, showing they correspond closely to the temperature reported in the EXIF data and don't rise above 64C. His next finding is that if you remove the internal battery it resets the so-called overheating limitations. So who is telling the truth now, Canon?
    You can view the most recent findings here by the user "Math Class" (Google translated)
    Read the full article on EOSHD:
    https://www.eoshd.com/8k/removing-internal-battery-resets-eos-r5-overheat-timer-are-canons-pants-now-completely-down/
  17. Thanks
    Stathman reacted to Andrew Reid in Canon EOS R5 overheated in my fridge! After just 60 JPEGs! (4 °C ambient)   
    Canon really threw the kitchen sink at the EOS R5 specs sheet. What about the kitchen fridge?
    Canon have stated overheating time limits for HQ video recording in a warm 23 °C room.
    How does the camera perform in much colder conditions?
    Does the EOS R5 still overheat in the Wifi menu in a fridge?
    Or do the cold temperature help cool the camera body, which Canon claims act as mitigation for hot components inside?
    Read the full article:
    https://www.eoshd.com/news/canon-eos-r5-overheated-in-my-fridge-after-just-60-jpegs-4-c-ambient/
  18. Thanks
    Stathman reacted to luizhmgoncalves in Sony A7S III   
    Using Resolve studio here.
    Once I turned then into 25fps they playback real-time on my PC.
    Trying to playback at 100fps it dropped frames. But in a 25 or 24 timeline it worked. Time stretched or normal, works really fine.
    My setup is a Ryzen 1600 with a Radeon Rx570 4gb, 32gb ram. Very similar to some Macs.
    My system struggles with the Canon R5 h265, 100% CPU usage dropping frames, but not the Sony ones, 40-50% CPU. Even turning the R5 files into 24-25fps doesn't make any difference. 
    But the Sony XAVC-I performed really close to prores, 25% CPU, and that is a great point for the A7s 3.
  19. Like
    Stathman reacted to androidlad in Sony A7S III   
    Graded and matched to Alexa using the above footage, with CineMatch plugin:






  20. Thanks
    Stathman reacted to Trek of Joy in Sony A7S III   
    More SOOC footage at 50/100p from the "No Limits" launch video by Jacques Crafford. 
    https://drive.google.com/drive/folders/1kYjaH84X9871d8-Rmuj9DOXfmtAH6V6i?fbclid=IwAR3LPZ7njD6UadrWtejYeGQHq5hfTCNOKXBrdliOZ4w4cvrja5IrzGgRnhY
  21. Thanks
    Stathman reacted to Andrew Reid in I bought a Canon EOS R5 - potential overheating solutions   
    So going back to the actual internal design of the EOS R5...
    The questions Canon need to answer are:
    1. Why is a circuit board sitting between the main CPU and back casing, blocking the heat from spreading away into the chassis
    2. Of course, why is there no thermal conductive material on the CPU?
    3. And why does the RAM thermal pad overlap onto the CPU, but not entirely cover it? (It seems to spread the heat from the RAM onto the CPU which is never a good idea).
    4. Why does ice not cool the camera and speed up recovery time? The firmware recovery countdown timer is so slow to go back up and always the same.
    And indeed they will be asked via my contact at Canon UK.
    And I won't let up until they answer.
    If they don't answer, they have something to hide obviously.
  22. Thanks
    Stathman reacted to Andrew Reid in I bought a Canon EOS R5 - potential overheating solutions   
    Yes that much is clear I'm afraid. To be quite honest, I don't want to hear any more bullshit from you. So please take yourself off to a different forum.
  23. Haha
    Stathman got a reaction from Katrikura in Canon EOS R5 / R6 overheating discussion all in one place   
    I have two propositions for their new logo.. 😎
     


  24. Haha
    Stathman got a reaction from majoraxis in Canon EOS R5 / R6 overheating discussion all in one place   
    I have two propositions for their new logo.. 😎
     


  25. Haha
    Stathman got a reaction from noone in Canon EOS R5 / R6 overheating discussion all in one place   
    I have two propositions for their new logo.. 😎
     


×
×
  • Create New...