XT-2 Glaring Omissions

[boblenstalk@gmail.com]

As a newcomer to the X system, I am truly impressed with the quality of the equipment and feel that my move from bulky and heavy medium format equipment (Leica S), which will, hopefully, allow me to continue to enjoy walking and capturing images in the mountains of northern Britain for as long as possible, has been justified.
However, like all camera systems, nothing is perfect and I would like to see the following common sense improvements in the first firmware update for the XT-2 and, to be honest, I cannot understand why these were not incorporated into the camera from the beginning, as they seem to be a nonsensical oversight:
1. The ability to zoom into 100% while reviewing images on the rear screen or through the EVF without having to shoot JPEG files along with RAW files.
2. The ability to review an image in camera which shows “blinkies” utilising the entire screen or viewfinder as opposed to showing the tiny image which is currently the only way to see a histogram and over/under exposed areas.
3. The ability to see an RGB histogram as opposed to the purely luminance histogram shown currently.

4. While I appreciate that retrospectively fitting a GPS facility to the XT-2 is impossible, I would ask Fujifilm to improve their smartphone app to make the GPS facility workable rather than the pain in the backside to use it currently is. I travel a lot and an accurate GPS facility, which I have on my Leica S cameras is an extremely useful, if not necessary tool.

[flysurfer]

#1 is impossible,

#2 and #3 have already been requested several hundred times since January 2011 (I heard the GFX finally offers color histograms),

#4 has been mentioned several dozen times since 2013, but is certainly only considered nice-to-have, not necessary.

 

Outlook: There's a chance that #2 and #3 will come in future models and maybe via firmware to the X-T2 (after all, the tethering plug-in offers color histograms). #4 is very unlikely to improve (better use an external real-time GPS tracker and merge the EXIF data later), #1 will never happen (Fujifilm doesn't do magic).

 

Recommended course of action: Write to your regional Fujifilm office and request features #2 and #3. 

[boblenstalk@gmail.com]

Thanks but I don't think I'm asking Fuji for the impossible with number 1 - if Leica and Sony (and Olympus, etc, etc) are able to provide a usable review magnification level, without shooting a superfluous (to me anyway) JPEG file in addition to RAW, I'm sure that Fuji has the capability.

GPS may be regarded as only nice to have but, given some of the remote locations in the world to which I regularly travel, for me and, I suspect, many others, it is somewhat more than nice to have. Leica has seen the light for years by including it as standard in the S system and now, I understand, Canon has done the same with the 5Div. Unfortunately, as there is no module in the XT-2, this can only be done by way of an app but that app is sorely in need of improvement.

I have already contacted Fuji but I suppose, as is usual in life, the more such contacts they receive, the more likely they are to listen and act.

Many thanks again for your comments.

Bob

[kimcarsons]

Yeah, #1 is definitely not impossible. The reason for the way it is now is probably just that X-Trans is harder to crop at arbitrary dimensions (i.e. to zoom in and pan around) than Bayer... Similar to how line-skipping is harder/courser with X-Trans (which is why Fuji's video was s**t until the latest gen which has a fast enough processor to not have to line skip). 

 

They can do it.

[flysurfer]

Of course it would be possible, but it's nothing most users would want, as it would slow down the camera and increase memory needs in the camera and on the computer drive. I would not tolerate RAW files that always include large, full-size JPEG previews. So if Fuji changes this, I will call them out with regards to this "glaring error". I am very sure others will join me. 

 

Now, if that would only come as another option (to further complicate things, which many Fuji users don't like), I could personally live with it (I'm not afraid of complex systems with many options). However, that option is already there. It's called NORMAL+RAW, and it's more versatile that forcing users to use oversizes RAW files, because we can use the full-size preview as long as we need them and then dispose of them later. Best of both worlds.

 

So no, I don't want this feature. It's already here, as far as I'm concerned.

Edited January 4, 2017 by flysurfer

[voodooless]

Of course it would be possible, but it's nothing most users would want, as it would slow down the camera and increase memory needs in the camera and on the computer drive. I would not tolerate RAW files that always include large, full-size JPEG previews. So if Fuji changes this, I will call them out with regards to this "glaring error". I am very sure others will join me. 

They would not need to to that. If you zoom past JPEG preview resolution, they could simply de-Xtrans the part of the RAW file that is shown on screen and apply the saved image display settings. It should not be to hard to do, and not need to cost a lot of memory not processing speed..

[flysurfer]

They would not need to to that. If you zoom past JPEG preview resolution, they could simply de-Xtrans the part of the RAW file that is shown on screen and apply the saved image display settings. It should not be to hard to do, and not need to cost a lot of memory not processing speed..

 

 

That (real-time RAW processing) would be theoretically possible, but consumes more energy. Also, the processors seem to work differently in playback mode, since it takes much longer to render a RAW in the built-in converter than it does in shooting mode. So this process would be pretty slow. For whatever reason, shooting and playback mode appear to use different processing pipelines. We know similar things from Lightroom CC, where Development mode can use the graphics processor to speed up things, but the rendered Full-Screen View cannot.

Edited January 5, 2017 by flysurfer

[voodooless]

That is no argument against, and it won't be slow either if done right.. It only means it is a bit more work to implement.. just like a good AF algorithm. I guess it just is not a priority for them.

[flysurfer]

That is no argument against, and it won't be slow either if done right.. It only means it is a bit more work to implement.. just like a good AF algorithm. I guess it just is not a priority for them.

 

 

They would need different hardware, so it's certainly no firmware update. They even told me that they'd need different hardware to enable 16 Bit TIFF output as an option.

 

It's no priority at all, because NORMAL+RAW already solves the issue and because this request has been formulated by less than a dozen users in the past 6 years. So NORMAL+FINE remains Fujifilm's solution, and if users don't like it, they better look elsewhere or wait/hope/pray for something that may or may not happen in the future. AFAIK, the new 50 MP GFX also works that way, given that it's based on the X-T2 processor. But I haven't checked it out, yet, I'll know more in a few weeks.

Edited January 5, 2017 by flysurfer

[voodooless]

They would need different hardware, so it's certainly no firmware update. They even told me that they'd need different hardware to enable 16 Bit TIFF output as an option.

No, they don't. The CPU is more than powerful enough to handle what I described, same goes for memory requirements. It just a shitload of work because I suspect it's quite a hack to implement.

 

Even for the 16-Bit TIFF I doubt that. You could just stream out the pixel data to a TIFF file pixel by pixel.. It is not rocket science. There is some complexity when you wan't to compress the TIFF. The most common schemes are based on ancient FAX technology.. again, hardly a complex task CPU and memory wise.

 

Don't get me wrong, I don't blame them for not implementing these features. I'm fine with not having either of them. I think it's just not correct to think that it cannot be done on the hardware available, even if someone from Fuji tells you otherwise. I even think it's bit ignorant of Fuji to tell you this, but I guess it's easier to say it cannot be done than telling you that they won't do it..

 

Would be fun though to brainstorm with an actual Fuji engineer on how to get it done

[kimcarsons]

There is some truth to the "it would require different hardware" statement. Cameras do not use their general purpose (usually ARM these days) CPUs for image processing. They employ one or more ASICs, which are chips designed to do one or more specific tasks very efficiently (demosaick, filter, denoise, encode x264, jpeg, etc). That being said, usually these chips are fairly versatile and probably even have TIFF and other codecs built in to them, as well as many other options, even if Fuji doesn't use them.

 

For example, GoPro has long used an Ambarella chipset which supports electronic video stabilization, but without giving the user access to that feature (although other manufactuer's cameras using the same chipset do).

Edited January 5, 2017 by kimcarsons

[flysurfer]

No, they don't. The CPU is more than powerful enough to handle what I described, same goes for memory requirements. It just a shitload of work because I suspect it's quite a hack to implement.

 

Even for the 16-Bit TIFF I doubt that. You could just stream out the pixel data to a TIFF file pixel by pixel.. It is not rocket science. There is some complexity when you wan't to compress the TIFF. The most common schemes are based on ancient FAX technology.. again, hardly a complex task CPU and memory wise.

 

 

Well, then the developers of the camera were lying to me when I discussed this topic with them – and the demosaicing ASICs (which seem only be employed in shooting mode) don't exist. It's all just the CPU and Fujifilm is lazy/stupid. Maybe you should offer them your services.

[flysurfer]

There is some truth to the "it would require different hardware" statement. Cameras do not use their general purpose (usually ARM these days) CPUs for image processing. They employ one or more ASICs, which are chips designed to do one or more specific tasks very efficiently (demosaick, filter, denoise, encode x264, jpeg, etc). That being said, usually these chips are fairly versatile and probably even have TIFF and other codecs built in to them, as well as many other options, even if Fuji doesn't use them.

 

One would think so, but then reality tells a different story. I'm sure many of us remember the switch from 97% JPEG compression to 99% compression in the X-T10 which couldn't be brought to the X-T1, X-E2 and even X-E2S via firmware, because the compression ratio was either hard-coded or limited by other hardware factors. Or Sony's inability to bring lossless RAW compression to their higher-end cameras via firmware after dpreview forced them to offer an alternative to their bad lossy compression scheme. In any case, Fuji's Tokyo developers told me that 16 Bit TIFF wasn't a firmware possibility even for the built-in RAW converter. Bummer, because this was actually a rather popular request. It's the same with IBIS. Fuji engineers insist that it's no option for X-Mount, but many armchair developers in various forums say it is. Maybe they too should offer Fujifilm their services.

[kimcarsons]

One would think so, but then reality tells a different story. I'm sure many of us remember the switch from 97% JPEG compression to 99% compression in the X-T10 which couldn't be brought to the X-T1, X-E2 and even X-E2S via firmware, because the compression ratio was either hard-coded or limited by other hardware factors. Or Sony's inability to bring lossless RAW compression to their higher-end cameras via firmware after dpreview forced them to offer an alternative to their bad lossy compression scheme. In any case, Fuji's Tokyo developers told me that 16 Bit TIFF wasn't a firmware possibility even for the built-in RAW converter. Bummer, because this was actually a rather popular request. It's the same with IBIS. Fuji engineers insist that it's no option for X-Mount, but many armchair developers in various forums say it is. Maybe they too should offer Fujifilm their services.

 

Heh. Well, I think Fuji's argument against IBIS is still BS, but at least they tried to come up with more of a reason than Canon and Nikon...

 

Re the TIFF issue, the whole situation is a bit of a farce. A failure of communication. The truth is, I think most photographers don't want RAW. They think they do because RAW is all they can get the camera makers to give them. But what they *really* want is 10, 12, 14 bit color in any format. Having cameras save in 16-bit TIFF is just another workaround (like RAW is). What's really needed is 12-bit JPEGs (JPEG2000?) or better yet, 14-bit JPEGs. I doubt anybody really needs the extra 0.000001% or whatever resolution they can eke out of RAW (or TIFF) over JPEG (FINE), they just need the extra color depth for post processing. I'd still rather have a TIFF than a RAW file... but, even compressed, they're going to be bigger than the RAW files, which are already huge.

[voodooless]

One would think so, but then reality tells a different story. I'm sure many of us remember the switch from 97% JPEG compression to 99% compression in the X-T10 which couldn't be brought to the X-T1, X-E2 and even X-E2S via firmware, because the compression ratio was either hard-coded or limited by other hardware factors.

I surely think lots of things will be hardcoded in hardware, for instance (parts of) the JPEG and RAF engines. You would however think that they would not make new silicon just for the X-T10. But who knows.

 

In any case, Fuji's Tokyo developers told me that 16 Bit TIFF wasn't a firmware possibility even for the built-in RAW converter. Bummer, because this was actually a rather popular request.

The CPU's could easily run a full linux system with libraw and libtiff.. That could do all you would need.. so, yes the hardware is definitely capable. The reason Fuji will not make these features is because the hardware is far form efficient in doing these things. The user experience would just not be acceptable (and no, they will obviously not install Linux). AF was crappy ones, then they spend some time on it, and suddenly it was pretty good. These things are hardly ever a yes/no things. Things might progress over time. Things though to be impossible now, might be possible later, even on the same hardware.

 

It's the same with IBIS. Fuji engineers insist that it's no option for X-Mount, but many armchair developers in various forums say it is.

Fuji never said it could not be done. They say that the physics of the mount are so that there would be to many compromises in image quality or image circle. They just think it is not acceptable. And they are probably right.

 

Maybe they too should offer Fujifilm their services.

I think I just did in my previous post.

Edited January 6, 2017 by voodooless

[kimcarsons]

The CPU's could easily run a full linux system with libraw and libtiff.. That could do all you would need.. so, yes the hardware is definitely capable. The reason Fuji will not make these features is because the hardware is far form efficient in doing these things. The user experience would just not be acceptable (and no, they will obviously not install Linux). AF was crappy ones, then they spend some time on it, and suddenly it was pretty good. These things are hardly ever a yes/no things. Things might progress over time. Things though to be impossible now, might be possible later, even on the same hardware.

 

Not acceptable indeed. Try to processing a 24MP image on your Raspberry Pi sometime. We're talking minutes just to apply the film simulation---forget demosaicking X-Trans on the CPU.