X-t5 Firmware
Dierdre Roussin
The firmware bugs have been fixed, which caused that the cameras rarely froze right after the completion of the firmware update with the current version using a smartphone (tablet) in which Camera Remote application software was installed.
If firmware updating fails, the camera may no longer operate correctly in some cases. Carefully read the notes provided here*Always use the fully-charged battery when updating the firmware as a basic manner. Never turn the camera off or attempt to use any of the camera controls while the firmware is being overwritten.
Moreover, in their recent official X Summit announcement, Fujifilm said they are currently considering further enhancements, which I hope will translate also on firmware love for those, who mainly use Fujifilm cameras for stills.
Disclaimer: Fujirumors has no affiliation with any of the equipment manufacturers mentioned on this site. Please visit their official websites by typing the specific brand name and adding .com after it in your browser. All trademarks and brands belong to their respective owners.
FujiRumors is participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.
FujiRumors is a participant in the Amazon EU Associates Programme, an affiliate advertising programme designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.co.uk, Amazon.de, Amazon.es, Amazon.it, Amazon.fr
The Kaizen syle of firmware is a substantial update that goes beyond just fixing bugs and issues; it adds new and improves existing features, breathing new life into existing cameras. This year already Fujifilm has updated the X-H2, X-H2S, and GFX 100 II, and users are now reaping the benefits of improved AF and video features.
Kalum's photography has been published and exhibited around the world, and he continues to photograph on a project-by-project basis. He is currently working on a personal project capturing the people and landscape of Gower, South Wales. Currently untitled, this body of work will be exhibited for the National Trust later this year.
The X-T5 is not the only camera that received a firmware update. Reala Ace is now available for all cameras with the X-Trans V sensor (X-T5, X-H2, X-H2s and X-S20) via the firmware updates released today.
Ich bin einer der Menschen, die seit dem Erscheinen von Reala Ace darauf warten, dass diese Simulation auch auf Kameras mit einem ASP-C Sensor gebracht wird. Anfnglich sagte Fujifilm ja, dass diese Sim nur fr GF-X Kameras verfgbar sein wird, da sie fr die Mittelformat Sensoren entwickelt wurde.
Das fand ich sehr Schade, denn die Prsentation damals bei der mit einer Fotografin welche die neue GF-X und Reala Ace auf einem Stdtetrip dabei hatte, die hat mich richtig eingefangen. Das waren so ehrliche Bilder, Bilder so wie man das Leben in echt gesehen hat, einfach ohne Rezept nur mit der Simulation.
Das machte mich richtig traurig, dass ich diese Sim nie besitzen sollen wrde, denn eine GF-X Kamera kann ich mir als Hobbyfotograf nicht leisten. Heute war es dann soweit, Reala Ace kam auf meine X-T 5 und ich bin geflasht, die Bilder sind so fein, so klar und bei allen Reglern auf 0, sieht das RAW neben dem JPG 100% gleich aus, das ist der Hammer!
I imagine that this is something Fujifilm could fix fairly easily via a firmware update. A simple tweak to the code could possibly make this behavior happen much less frequently. Fujifilm should address this issue. I hope in a few months from now this will all be a past problem that was fixed and forgotten. Or it could be the expected behavior that all Fujifilm X-Trans V cameras will have, and it will only be fixed by an even more improved AI-AWB on X-Trans VI models. Time will tell.
Dear Ritchie,
There is an easy and direct solution for this problem. I seldomly use AWB at all. But when I use it I use it together with the AWB lock. I have set one function button to switch the AWB lock on or off. So when I think the AWB has found the right colours, I switch the AWB lock on as long as I stay in the scene. When I leave the scene I turn it off.
Hope that helps
Karl
The AI is in beginner mode, like me when I discovered WB I used to try whites to always be white; or my Sigma DP2 which I forced in settings to sunny but jumps from greenish Matrix to bluish half developed film. In the photo I prefer the golden tones in the right, it is how I would remember the scene, at the left is more about how machines can register reality.
this is similar to the AWB of my nikon d610, it can also take the tint in some direction with a slight change in the same light conditions. Do you think the 610 also uses a AI AWB? =)
OF course this is a joke, but it is surprising that the old problems of inaccurate white balance now arise in the latest developments where AI are involved.
During the Summit, the XF lens roadmap for the near future was mentioned. The brand has decided to substitute the popular XF18-55mm F2.8-4 kit lens for a new one. The new kit lens for the X series 5th generation will be the new Fujifilm XF16-50mm F2.8-4.8. More than ten years after the previous kit lens was released, Fujifilm wants to improve compactness, versatility, and sharpness with the new one.
Finally, the release of XApp 2.0 is scheduled for February, featuring an updated activity page. Users will now have the capability to view all images captured with a particular camera lens by simply tapping on it and selecting pictures taken with a specific film simulation in the camera roll. Fujifilm has also added a new equipment page with a shutter count (finally!) and battery status.
It is nice to see a brand continually improving their cameras, even those that have been in the market for some years. As we install these Fujifilm firmware updates, there is the feeling of not being outdated or forgotten by the brand. As a Fujifilm user, I appreciate this philosophy from the Japanese company.
You can unsubscribe at any time via an unsubscribe link included in every newsletter. The data provided and the newsletter opening statistics will be stored on a personal data basis until you unsubscribe. For further details, see our Privacy Policy
I am working on a project using the STM32WB55. I would like to distribute an "official" firmware, but also allow third-party firmware to be installed. The intent is that the official firmware will be open source, so users can make changes to the official firmware and upload their own firmware to the device.
The catch is that the official firmware will include private keys (not part of the open source distribution, obviously) used for signing its output, so that users can verify that the output was produced by the official firmware, as opposed to a third-party firmware. This means:
The main question, in my mind, is whether X-CUBE-SBSFU security relies on only "official" user applications being installed. As near as I can tell, this is not the case, since several protections are in place by the time the user application is executed:
What you could add in SBSFU could be some specific information in the header to tell about origin of the firmware. If this is official firmware you go through normal SBSFU. If this is open source, then you could either use another set of keys.
I was thinking of disabling the signature check on boot, since we don't need to ensure that only official firmware is installed in this application. At least, this is not a requirement for the application itself, but one thing I'd like to hear your thoughts on is whether this introduces any security concerns I should be aware of. If I understand correctly, the signature check is generally included for business reasons--e.g., to control which features are enabled on the hardware--rather than for security reasons. Would skipping the signature check (i.e., allowing unofficial firmware to be installed) introduce any serious security issues?
My thinking is that the security measures mentioned above (RDP, IWDG, WRP, MPU) can be used to prevent unofficial firmware from accessing private data (e.g., the encryption key for the official firmware).
With the signature check removed, a partial firmware update would introduce a security flaw, I think, since an attacker could replace only part of the official firmware, and use that replacement code to read out proprietary information (e.g., the key used to sign log files) contained in the official firmware. This is why I mentioned disabling partial firmware updates--because by erasing the whole firmware before installing third-party firmware, I think we eliminate this attack.
Again, the potential issue I see is that this opens up possibilities for an inside attack (i.e., from an installed unofficial firmware), but as near as I can tell, the available security tools allow us to protect against this issue.
Besides, storing private asymmetric keys in the bootloader with only MPU protection will not work in your context. Reason is that any application can change the MPU configuration. It is up to the application to actually setup the MPU configuration.
Ah, of course. You mention that "only MPU protection" won't do the trick--is there another protection strategy which might allow a private asymmetric key to be installed on the device, while still allowing third-party firmware?
4a15465005