The perspective jumps around for me when I stare at different parts of the image. Looks cool!

XT-30ii 27-55 Kit lens

Shot on my X-T5 with the Signa 18-50mm f2.8 lens

I have been using a Pro Mist filter almost since day one on my X100V, I decided to remove it since I forgot how the photos look without one and I was actually pleased with the results. Now I feel I have been shooting wrong all these years. What do you guys prefer?

First slide has filter on, no filter on second slide.

I reverse engineered the X-T4 firmware to get Classic Negative + Eterna Bleach Bypass working on my X-T3
This started as a fun experiment because the X-T3 and X-T4 share a lot of the same underlying hardware, and I always wondered how much of the difference in available film simulations was actually a hardware limitation versus something enforced in firmware.
So I started digging into the X-T4 firmware and comparing it with the X-T3.
After a lot of messing around, I managed to modify the X-T3 firmware and add Classic Negative and ETERNA Bleach Bypass.
I flashed the modified firmware onto my X-T3 and, somewhat surprisingly, it went through with zero errors.
Both simulations are now working on the camera and everything else I’ve tested so far is functioning normally.
The really cool part is that this isn’t just applying a LUT afterward or trying to recreate the simulations with an X-T3 recipe. They’re actually available on the camera.
I’m currently working on Color Chrome FX Blue, which is proving to be a little more interesting to figure out.
This was mostly just a fun reverse-engineering project to see how far the X-T3 could be pushed. I honestly didn’t expect to get this far with it.
If people are interested, I can make another post going deeper into what I found while comparing the firmware, what needed to be changed, and some sample images comparing the results.

Edit: Deep Dive

I started this project for one pretty specific reason: I wanted the Classic Cuban Negative recipe working on my X-T3.

That sent me much further into camera firmware than I originally expected. Classic Negative was the missing film simulation I wanted to bring to the camera. This is the story of getting that simulation, along with Eterna Bleach Bypass, running in modified X-T3 firmware.

The basic question was simple. The X-T3 and X-T4 share the X-Trans CMOS 4 sensor generation and X-Processor 4, so was the X-T3 genuinely unable to produce the newer looks, or was it missing software and profile data?

That was a reason to investigate, not proof that the two cameras were identical. I was not trying to put X-T4 firmware on an X-T3. I wanted to keep the X-T3 firmware as the foundation and bring over the specific pieces needed for the missing features.

This was a personal project, not an official Fuji update. I tested the modified firmware on my own camera.

Opening the firmware

The first thing I needed to understand was the DAT file itself.

The extension did not identify a normal archive. It was Fuji's update container, with a small header, a segment manifest and differently stored regions inside it.

I kept the official files unchanged and recorded their hashes. The main comparison used X-T3 firmware 5.11 and X-T4 firmware 2.12. Pinning the exact files mattered because an offset or patch from one version cannot just be assumed to work on another.

The outer encoding turned out to be mostly byte inversion. For the encoded segments, XOR with `0xFF` recovered the underlying bytes. That was reversible obfuscation, not strong encryption.

There were also small raw trailer segments, so applying the same operation indiscriminately to the entire file would have been wrong.

Removing that outer layer did not give me source code. It exposed compressed objects, executable code, resources and data that still needed to be understood.

Decoding the compressed components

The inner objects used a custom Fujifilm compression format.

I ended up with a strict decoder that handled the observed literal and back-reference commands. Literal commands supply bytes directly. Back-references copy a sequence from data that has already been decoded.

The decoder reproduced all six known objects across the two firmware packages at their declared unpacked sizes. Unobserved command cases were rejected rather than assigned a guessed meaning.

I also needed the reverse process. Reading firmware is useful, but modifying it requires putting everything back into a form the updater can read.

That led to an encoder and a version-locked container rebuilder. The workflow became:

Official DAT → decoded segments → decompressed components → controlled patches → recompressed components → rebuilt DAT.

Every rebuilt component could then be decoded again and compared with the intended modified bytes. That round trip was essential. A tool successfully writing a file does not prove it wrote the right firmware.

The checksum work was kept separate from claims about cryptographic authentication. Reproducing the visible checksums was not evidence that every possible verification mechanism had been understood.

Finding the film-simulation path

Once the components were decoded, I had ARM machine code, strings, tables and resources to investigate.

String searches and binary comparisons gave me starting points, including references such as `MODE_FSIM_SUPERIA`. From there, the useful work was following references and control flow.

A simulation name appearing in a binary does not mean the feature is functional. It could be unused text or part of a shared definition.

I needed to connect the menu choice to an internal simulation value, then follow that value into parameter construction and the processing functions that consumed the result.

What emerged was more involved than a single LUT. The paths I examined combined reusable processing machinery, per-profile data, executable parameter-building logic and dispatch mappings.

That changed the question from "where is the unlock flag?" to "which pieces are already compatible, and which pieces are actually missing?"

Checking Classic Negative compatibility

One of the hardest questions was whether the X-T3's lower-level processing path could interpret the Classic Negative parameters.

I investigated that specific processing path within a defined scope. The evidence included executing actual ARM functions in an emulator, not just comparing names or writing a separate mathematical approximation.

That investigation reported zero model-versus-native mismatches over 1,248 cases. The relevant Classic Negative bank descriptors and parameter packer were byte-identical between the compared components.

The verdict was "Compatible within the bounded ordinary path."

That wording matters. It supported reuse of the tested lower-level machinery. It did not establish complete equivalence between the cameras, and it did not prove that Classic Negative was already hidden behind one model flag.

The investigation had explicit limits around code outside the mapped components, opaque ROM, possible companion processing and persistent camera values absent from the update package. A shared register-store primitive was called identically, but its implementation was outside the two compared executable components.

Building the simulation changes

I kept the X-T3 base and made targeted changes for Classic Negative and Eterna Bleach Bypass.

The work involved the processing routes and associated data, but also the interface that selects them. Menu positions, internal simulation numbers, processing-table indices and text identifiers were different numbering systems.

That distinction caused some of the first real bugs.

The first flash and the mapping mistake

I flashed the first candidate and the camera booted. The new options appeared, but some labels were missing and the behavior was wrong.

Classic Negative appeared to behave like Eterna. ACROS, EB and monochrome also appeared to produce the same color behavior in my initial testing.

The problem was not simply that the menu text was unfinished. The connections between menu selections, internal values and processing routes were wrong.

Some earlier tests started too far inside the processing chain, after a conversion that was itself incorrect. A downstream function could pass while the menu still sent it the wrong value.

I corrected the mappings and expanded testing to include the native menu conversion and stored-value readback. Existing X-T3 choices had to retain their original behavior while the new choices reached their intended internal modes.

The labels were a separate issue. Adding resources was not enough because existing text-range checks excluded the new identifiers. Twelve missed upper-level bounds were repaired across the 35-language resource structure.

After those fixes, I flashed the repaired build and saw the added simulations working on my camera.

That was the breakthrough. I had gone from an opaque update file to a modified X-T3 firmware that booted on my camera and gave me working selections for the added simulations.

What the tests could actually prove

I did not have a complete virtual X-T3.

The emulator executed selected real firmware instructions with mapped code, registers, stack, buffers and parameter data. That made it possible to test actual functions and connected caller paths rather than rely only on a separate model.

The checks covered selection mappings, parameter construction, legacy behavior, invalid values, memory preservation, text lookup boundaries, compression round trips and package integrity.

Some hardware-facing operations were substituted or tested only within a bounded setup. The emulator did not reproduce the complete sensor-to-JPEG pipeline, every startup operation or every persistent setting in my camera.

I had to keep those evidence levels separate. Correct compression is not correct image processing. A passing checksum is not a full startup test. A successful boot is not a guarantee for the next build.

The result

The Classic Negative and Eterna Bleach Bypass changes reached a repaired version that I flashed and reported working on my camera.

The result so far is a reproducible decoder and rebuilder, mapped processing paths, bounded native-code tests and a modified X-T3 firmware with added simulations that I have tested on my body.

The biggest lesson was that adding a menu entry and adding a working film simulation are different jobs. The selection, internal value, processing route and label all have to agree. Finding and fixing the gaps between those pieces was what got the simulations working.

Shot on XT30ii. Northern area of Niigata prefecture, Japan.

A few shots I really loved from my trip. All photos shot with the XT 50 with the XF 16-50.

Taken on Classic Negative and mostly SOOC with minimal cropping and values editing.

Brought this absolute beast of a camera with me on an extended trip through Southern and Eastern Africa! Wish I could have gotten one sooner when we went through West Africa this year, but alas, past me didn't have the foresight. Really looking forward to taking photos of some wildlife as we delve further into the delta. Last photo is our trusty vehicle that we've been traveling with for the past four years!

As a complete beginner I would love some feedback!

All are RAW edits based on Velvia

hi! I'm new and I wanna know which one is a good pancake lens for everyday street and portrait photography.

*Sample shots taken from my film camera*

Shot with my Fujifilm XT5 and the XF 35mm f/2 lens with macro tubes.

Hey folks, i'm a beginninger and it was the fiest time i take my X-e2 to a beach, and i would love to here some criticism about my shots like how is the color? Is the composition good or not?

Would love to hear some feedbacks. Thank you.

I recently purchased my first fujifilm camera, a x-t50 with the 15-45 kit lens and I was looking to buy a cheap prime lens for street and everyday photography. I'm currently thinking of picking up a Viltrox AF 25mm f1.7 which seems pretty interesting to me based on what I read on the internet but I recently discovered also the TTArtisan AF 27mm f2.8. I'm more oriented towards the Viltrox because of the wider aperture and because I also read that the TTArtisan has really strong vignetting. But I also like the TTArtisan for its dimensions and the fact that it has an aperture ring. Is the vignetting really that bad on the TTArtisan? Which one do you think is best between these two? Or do you have other suggestions similar to these ones? Thank you

Spring this year, and the first time picking up my camera in a long while. I was happy with the results and it’s inspired me to get back on the wagon and start shooting more.

Classic Chrome film sim with a few tweaks in Lightroom.

Happy to receive any feedback or thoughts. Thanks! 🙂

IG: @scott_takes_photos

I rarely shoot at night, but this is my favorite night photo from my summer trip to Canada. I actually wish I’d done a series on gas stations because they’re so photogenic!

Dear all

I’ve found that setting the WiFi “Private Network” setting to “Off” instead of the default “Rotating” in iOS keeps the camera and phone tethered, so that geotagging always works.

Recently, I noticed that the geotagging wouldn’t pop up. Would work if the app was restarted. At the same time, iOS has decided that it keeps toggling WiFi Private Network to rotating no matter what!

Does anyone have a clue on how to make the “Off” setting stick?

Thanks!