Latest Fuji X-trans vs Bayer, has X-trans lost it already?

HatWearingFool wrote:

Brian Griffith wrote:

HatWearingFool wrote:

michaeladawson wrote:

The X-Trans design was applied to 16 MP sensors in Fujifilm's first generation mirrorless cameras (e.g. X-Pro, X-T1). At that time X-Trans cameras had two benefits; increased resolution due to removal of the AA filter and reduced color moire due to the different CFA pattern.

At 24+ MP on an APS-C camera most competitors have removed the AA filter from their Bayer equipped bodies. So as a practical matter there should be little difference in resolution between Bayer and X-Trans sensors with the same MP count.

There still seems to be a small advantage with color moire reduction at 24MP for X-Trans compared with a Bayer equipped sensor. The advantage should be further reduced if competitors start introducing 30+ MP cameras.

So the question that is often debated, with no definitive answer, is whether the X-Trans CFA is worth it due to the extra processing power needed and the different handling required for raw developer software.

The X-Trans CFA also makes it much more difficult for Fujifilm to implement things like pixel shifting. That doesn't matter to me but it does to some.

I agree that a shift to bayer would mean little one way or another to end results. But Fuji is using x-trans as a product differentiator in an attempt to add some cachet to their higher end models. It would be difficult for them to walk back the marketing talk now. But maybe if they come up with something else, or someway to sell a new implementation (processing) of bayer?

But this is the second time today I've seen people talking about the extra processing power required for x-trans raws? Has anyone actually experienced a difference in system requirements for processing equivalently sized bayer and Fuji raw files? I've never noticed any speed difference between processing 24mb Sony bayer raws and 24mb Fuji x-trans raws. I'm really curious if this is a real thing?

The X-Trans sensor pattern takes significantly more processing to handle well than the Bayer sensor pattern. In X-Transformer you can fairly easily run a side by side test comparing the RAW processing speed by disabling (setting to None) the sharpening, noise reduction and lens correction options. This basically isolates the processing to just the demosaic (or interpolation) of the sensor pattern, there is some file loading and saving time still that will be shared regardless of Bayer or X-Trans, but you should find that the X-Trans sensor takes about 2-3x longer to process than an identically sized Bayer file.

For example you could compare an X-H1 (24MP X-Trans) to X-A7 (24MP Bayer) and the Log window (Command/Ctrl-L) will show a time of conversion for each file.

The RAW processing is only one portion of the whole processing time and depending on computer performance the demosaic may not be a huge time cost overall, but its not an insignificant portion of the typical RAW processing time either. Some RAW processors obviously will be faster or slower than others with Bayer, same goes for X-Trans, but if reasonably similar quality is desired in my opinion X-Trans will always be notably slower. The X-Trans pattern just requires more complex interpolation and other processing to provide good/similar results to Bayer and there are no magic shortcuts to faster speed that don't sacrifice some quality/artifacts.

Brian Griffith (author of X-Transformer)

Iridient Digital

Thanks for taking the time to post. Obviously since you have hands on experience working with both file types your opinion carries considerable weight.

Any thoughts on the results posted above? https://www.dpreview.com/forums/post/63562728

As briefly noted, there are faster and slower Bayer methods of interpolation (demosaic) just as there will be with X-Trans. Some methods may be better optimized (OpenCL, multi-threaded, SSE/vector optimized, etc) than others and same would apply to X-Trans methods.

You certainly could create very processor intensive Bayer demosaic methods (the amaze method noted in above link for example may lie on the more processor intensive end of the scale for Bayer) that would be slower than an X-Trans demosaic.

Adobe's "enhance details" method would be another example of a slower, more processor intensive demosaic method. In Iridient Developer I offer several methods with a range of speed and quality.

I wouldn't be shocked (I have not personally done this speed test though) if the "enhance details" speed of Bayer compared to normal Adobe processing of X-Trans might show a speed advantage to the normal X-Trans, but in theory the quality of the "enhance details" Bayer processing would be notably higher quality than the standard Adobe processing of X-Trans.

In my experience, given a goal to get similarly good results, reasonably quickly and at a reasonably high quality level out of both Bayer and X-Trans, the Bayer pattern is inherently easier to process with good results and fewer obviously objectionable artifacts and therefore will be faster to process given similar efforts at speed optimization.

If fast processing is the primary goal (say for quick preview) my experience there too is that the Bayer pattern is inherently easier to process quickly. You can get a decent preview image out of Bayer more quickly than X-Trans even if you are willing to sacrifice some quality with X-Trans.

Brian Griffith

Iridient Digital