I am an amateur photographer, and I can't understand why the major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't open at least to the concept of SDK's to control their cameras (let alone opening the lens mount specifications)...
It would make their cameras much more flexible and useful, thus perhaps gaining some users that currently use smartphones where it seems there is greater control over and integration with the cameras. On the other side, if one can implement in software what the producer doesn't want to implement in firmware, they might miss some future upgrade sales...
I am currently thinking on buying a FujiFilm X-T4, and I was pleased to see there is a SDK, but now, finding out that using the SDK is practically forbidden (until the warranty ends), it makes me stop and think about my decision... What could the SDK do to the camera so that it voids the warranty? (On the other hand, given the quality of camera brand produced software, I can imagine the quality of the code that went into it...) :)
For the bigger players, they miss out on market segmentation. An EOS M with Magic Lantern has a number of features that are featured on Canon's cinema line, for example. The M is perhaps no longer competitive in key ways, but had ML been available with today's level of polish in 2012, it would have eaten into higher-margin products.
Fuji is perhaps best poised to enable open development -- their pricing structure is more around hardware variations on a common sensor/processing than strict differentiation in capability.
The far future of camera development probably does look like open-source (or, at a minimum, common-versioned closed-source) software/firmware riding on commercially-manufactured hardware platforms (just like computers today). We're not there yet, but the technical success of Magic Lantern shows that the door is open.
A dark-horse entrant like Sigma could, in addition to Fuji, be a hardware vendor that could crack open a "commoditize your competition" market.
In the meantime, everyone except professionals and image-quality obsessives has moved to phone cameras, for which Google and Apple have developed incredible software. It's been obvious for at least ten years that camera makers need to improve their software, and they've not done so, or very minimally done so.
I don’t think that Canon and similar could offer anything to compete with smart phones. While smart phone cameras have gotten much better, the real secret sauce is that everyone already has a smart phone. It’s not that smart phones beat DSLRs, its that they got sufficiently good and everyone got them for other reasons. Not having to buy and carry a second device is quite the market advantage, it turns out.
Frankly, no dedicated camera is ever going to win back users with software features, and it is extremely unlikely that Canon or Nikon could out compete Apple and Google in this area. It makes much more sense for Canon to continue to serve hobbyists and pros with features that phones cannot offer, rather than trying to complete on software.
Maybe they're working on something big, but Canon, et al. to me appear to be headed the way of Kodak, at least in the consumer market.
They would have a hard enough time with casual users just because the camera on their phone is "free" (included in the price and perhaps more importantly, the form factor). But I don't even see any attempt to compete with Apple or Android cameras.
I use a full-frame SLR, and love my lenses. But I put it at even money whether I will ever buy another.
My experience is that the phone can do just as well as the real camera for shots which are easy to take. I still go for the real camera in situations where it's not so easy. (High zoom, need to focus on something other than the foreground (say, an animal with vegetation in the way), slow shutter speed to compensate for inadequate light etc.)
For me it is not a matter of obsession, I just enjoy using the equipment. I also take loads of photographies with an iPhone and an Android phone and, invariably, they fall short of the full frame or APS images. Specially when you print them on anything larger than A4. I agree that for screen only, phones are enough.
Raw video on M magic lantern looks absolutely stunning unless you explicitly need 4K to my eye and manipulation beats hands down droll quality of compressed video.
> I am an amateur photographer, and I can't understand why the major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't open at least to the concept of SDK's to control their cameras (let alone opening the lens mount specifications)...
At least Canon and Nikon do.
I use the Canon and Nikon SDKs in a product for work, and there are plenty of third party applications which allow control of their cameras.
They might not officially offer support for them, but they do keep them updated for new cameras and I have had bugs fixed and questions answered.
There are open source projects using these SDKs - See NINA [0] as just one example.
The Sony mirrorless cameras used to have some third party "apps" that were pretty cool but apparently are now all discontinued. And what the Magic Lantern team did for Canon cameras (especially the 5DmkIII) was absolutely amazing. I still miss features to this day.
If you are looking for a new camera also definitely checkout the new Panasonic Lumix line of full frame cameras - they are damn amazing. Extremely intuitive UI, tons of features you do not find in other cameras, amazing video (especially with an external recorder - you can do 6K raw video) and built like a tank. And they all use L-Mount which is shared among multiple camera manufacturers with tons of lenses available from Sigma and others. The Panasonic lenses are pricey but also extremely high quality (probably because they also design super high end cinema glass)
I strongly suspect it's just easier from a customer support point of view, if you develop an application that causes the camera to overheat and fail.
They really don't want to send you a new camera. The dangerous thing with code controlling hardware directly, is absent safe guards you can easily exceed the mechanical limits of the device.
This is why seriously overclocking a CPU will definitely void the warranty, but at the same time CPUs are often marketed based on how well they handle overclocking.
But in this case, the camera processor still retains final control over the commands from the SDK. This isn't a customer firmware, just a networking interface that simulates pushing buttons and changing menus. The firmware has just as much ability to reject damaging commands as it would if the user was physically entering them.
An external intervalometer can. And in any case, both in both the SDK and the intervalometer case, the camera's OS is free to just stop functioning, to prevent any possible damage to the sensor or shutter mechanism due to overuse.
That was my thought, also. You very well might be able to do things with the SDK that no human can do. The Therac-25 disaster comes to mind--a sufficiently skilled operator could inadvertently command it to become a death ray. (The trigger condition was to change it's operating mode while it was still executing the previous mode change command. Your average operator couldn't enter orders fast enough, but the fastest people could. It was supposed to work at high power with a target in the way to convert the electron beam to x-rays, or at low power as a direct electron beam. Confuse it and you got the high power mode with no target in the way and a fried patient.
So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it? What about a laptop? And a Camera is different how?
In the end it would be faulty / bad design that makes the Camera fail. And that is absolutely a valid reason the RMA it.
> So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it?
Kernel code can absolutely brick your PC due to how much it can do. This could be fixed at a UEFI/microcode level, but not without taking a lot of control away from the OS and the end user.
Japanese gov/corporations have a natural aversion to directly dealing with customers at scale.
They’ll want a proxy layer of third party corporations, which can then deal with the minutia of exposing it to end customers. Canon/Nikon/Fuji/Olympus have SDKs and partnerships, they just don’t want to deal with the individual customers.
If I had to put it another way, it's in their DNA to outsource scaling problems to middlemen.
The country's whole economic structure is a pyramid of sub-contracting companies that live and die on absorbing the scaling/operational risks for the bigger fishes.
> I can't understand why the major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't open at least to the concept of SDK's to control their cameras
Because why give something out for free when you can offer that stuff only in the most expensive models?
Well, the camera is already ~1.5-2K EUR (without lens), thus I think the price already covers it... But if I must put a price on it, I would say ~100-200 EUR, but then it should come with at least 5 years of updates, and it should work on Linux. :)
Also, just supporting some basic features, like shutter and all the exposure settings, shouldn't be that hard... I bet all of these are already implemented, because many cameras have smartphone applications that do allow to control all of these.
Thus, the largest cost would be mostly documentation, packaging and support for the various OS. Which, although might end up being quite a non trivial amount, it could be seen as money well invested in brand building, especially since now, in 2022, only professionals or invested amateurs are buying these dedicated cameras...
> Which, although might end up being quite a non trivial amount, i
Right. Engineers usually underestimate how much this really is. Often by an order of magnitude or two.
I'm pretty confident their margins aren't fat enough they'd be happy considering eating 1-2% (i.e. your numbers) on something that might help a fraction of install base. Hell they may already not be making next to nothing on these bodies.
So it would be a real project, and it would cost them enough that (using your rough numbers) they'd need to sell probably a few thousand support contracts a year to justify doing it properly (supporting multiple cameras, customer support, testing etc.). So I imagine if they have looked at it, they've balanced that against the "brand building" as you put it, and aren't sure it's a net win.
The prosumer space is funny for stuff like this, as people are often quite capable but not really willing to pay enough to justify the cost of real support. Some companies solve this by throwing something unsupported/unofficial over the wall, others (or their lawyers) decide the whole thing isn't worth the hassle.
I would happily pay a subscription for an iOS app. The usual argument against this is being commodified, but for the vast majority of the market, Canon has already been commodified in the shape of Apple and Samsung phones. They have to compete now on how good their hardware is, but their "stupid" hardware doesn't cut it without smart software. Their time in the broader marketplace is gone. They can get a small amount of marketshare back if they can make their hardware work with iPhones and Galaxies. Possibly just iPhones.
I've got the cash for a great canon camera. I used to carry one around with me all the time. The size isn't what's stopping me. It's the UX.
Canon has an app for that. Actually, a couple of apps for Android and iPhone. They also have desktop apps (mac and pc) that I use to control everything from focus to shutter speed, etc. Very useful to nail the focus on a large screen for reprography work.
I'm not sure they have looked at it, and I'm not sure they'd even examine this from an ROI point of view.
Camera makers (even camera divisions in more "high-tech" companies like Sony) are very much traditional hardware-first companies, I'm fairly certain he idea of opening up the cameras is just alien to them.
For a while in the late 1990s, there was a nominally-open camera OS called Digita. I had a camera that it ran on, and none of the skills to take advantage of it, but I remember someone built DOOM for it so that was neat.
People were writing Digita programs to do things like eat NMEA0183 GPGLL sentences and stuff them into the EXIF tags, because USB wasn't ubiquitous yet and a lot of cameras still had RS232 ports and cameras certainly didn't have native geotagging yet, but someone figured out it would be useful.
It was pretty wild, and I don't know why it flopped.
In terms of mount spec, I think Four Third and the successor Micro Four Third is open specification, then the Sony E mount later (not at launch time) open the specification.
The later might not be true, may be it is specification available but not open.
And practically any mount has been reversed engineered in their electronic protocols. (Edit: but each company has their own secret sauce here.)
As a digression, there are open source projects for running softwares or at least custom firmware in cameras. Famous examples are 2 projects on Canon compact and DSLR lines. Others includes firmware on Panasonic cameras, and then apps on Sony cameras. Sony may have killed the app capability due to this in recent models (or may be they only killed it because the store isn’t profitable.) If true that proves your point that they hate people tinkering it.
Canon always has been silent about the custom softwares running on their cameras including the famous 5D Mark II for raw videos. But later on as there’s rumors that the ID C cinematic camera ($10,000+ specialized in cine) is not much different than the then current 1D mode (may be 1D X, can’t remember) and it may be possible to hack it and install the 1D C firmware on the 1D camera (which is a relative bargain around $6000 or may be more.) Those rumors call out the open source project for help, and Canon for the first time spoke about the subject and signal that they will sue if anyone tamper with their flagship camera. Then the open source project responded saying they are not interested.
So again it’s another support on how much they hate us to tinker with our camera.
I’m guessing it may be a Japanese culture thing. Nintendo also has similar behavior. But may be not.
> In terms of mount spec, I think Four Third and the successor Micro Four Third is open specification, then the Sony E mount later (not at launch time) open the specification.
They're not. MFT can be licensed by "anyone", Sony E can be licensed only for producing lenses under additional NDA-covered criteria. DSLR mounts were sometimes licensed in a somewhat similar fashion, e.g. Tokina had a license for Nikon's F-mount.
> I am an amateur photographer, and I can't understand why the major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't open at least to the concept of SDK's to control their cameras (let alone opening the lens mount specifications)...
I don't know about the other brands but Nikon cameras have implemented PTP in full forever which allows you to set virtually every option remotely, albeit over USB. I'm assuming the other brands are similar, because that's how tethered shooting works. There is no camera-specific SDK or driver needed for this. The bluetooth and Wifi stuff is proprietary ad vendor-specific as far as I know, though.
This is a bit off topic, but I have a Sony a3000 and a6000. I have a non-sony USB camera timer/remote [1], and I'm pretty pleased with it. There seem to be similar products out there.
If there is no USB SDK released by Sony, how are these manufacturers creating this USB control devices? Do they partner with camera vendors behind NDAs? Do they reverse engineer the protocol? Just curious.
Not sure, but wanted to toss out there's apparently a github project that does USB Control for at least some Alphas. [0].
In the case of USB type things, it's probably a bit easier to 'sniff' traffic and reverse engineer the protocol if one wants to. And while some MFGs are notorious for being 'protective' around their protocols (i.e. lenses) I think remote controls are likely not as much a bread and butter to them, so there's less incentive (especially without obsoleting a lot of existing kit.)
Gating features allows them to wait for a future model to release them there and drive sales. There's not much blood left to wring from the digital camera stone.
They don’t want to cannibalize the other product markets. Canon for example was caught up with the video features that they added to the 5d back in the day. it sparked a video revolution, but destroyed their camcorder sector. same thing again when they released “cinema” specd cameras, that really just had different firmware than the photography cameras, but priced much higher.
A standard camera lens will not remain in focus while zooming. Cinema lenses have to--imposing restrictions that cause the lenses to be a lot more expensive. (A cinema lens works fine for still photography, but why pay the price/weight premium?)
Parfocalness can be emulated in firmware (by adjusting the focus as the zoom changes).
What you probably should have pointed out is the opposite property: keeping the same focal length while changing the focus distance. This can't be emulated in software because camera lenses don't have a motor on the zoom (plus primes don't have a zoom). Some cine lenses do achieve this by moving a zoom-like group (I think all the ARRI master primes do) and not just by being telecentric on the exit side.
Most big global brands are getting into rent seeking because the technology allows it, even company's like GE aka General Electric have diversified from making light bulbs to making money from finance activities so there is bound to be a reason for this avoidance to have an industry wide sdk. They may also want to avoid being labelled a cartel like this one https://en.wikipedia.org/wiki/Phoebus_cartel because legislation isnt brilliant either, just look at dieselgate, all the major motor manufacturers were engaged in the activities but because of US and UK national debts and deficits, Obama went after Merkel and Germany to get them to spend some money and they didnt so dieselgate appeared! Things are never what they claim to be in the news either.
However the flip side is, many global brands sponsor directly or indirectly university's around the world, and research is not cheap, if you saw the recent iphone lens exploded diagram a bit like this one https://wccftech.com/apple-working-new-iphone-camera/ you would see there is a lot of work going into all sorts of devices and the low hanging fruit from optics was harvested decades ago.
> Most big global brands are getting into rent seeking because the technology allows it, even company's like GE aka General Electric have diversified from making light bulbs to making money from finance activities ...
That's factually wrong. While Finance was a big part of GE in the early 2000s it all pretty much unraveled after the financial crisis[1].
Money quote :
"GE Capital is the financial services division of General Electric.[1]
The company currently only runs one division, GE Energy Financial Services; it had provided additional services in the past; however, those units were sold between 2013 and 2018."
The sony cameras support a fair amount of external control, I’ve never written code for it directly but third-party apps have no issue other than the requirement that you connect to the camera as a wifi access point, which is a pain but understandable.
> Subject to the terms and conditions of this Agreement, Fujifilm hereby grants to you a limited, non-exclusive, non-transferable, and royalty-free license to;
(a) use, modify and make a limited number of copies of the SDK solely for the purpose of the Development;
Later in the same agreement...
> 3.5 You shall not (and shall not permit others), to reverse engineer, reverse compile, or disassemble the SDK in any way(in whole or in part); and you shall not (and shall not permit others) to use any method to trace, decompile, or disassemble the SDK.
An SDK typically isn't a binary blob - it's usually a collection of header files you can integrate into your projects, media assets, config files etc. All of those can by modified by hand without disassembling anything.
That is true. It would be interesting to see this played out in court. When there are doubts around a certain clause on a contract of adhesion/license with non-negotiable terms, courts tend to side with the interpretation most favorable to the consumer.
SDKs are normally a bunch of function headers and documentation explaining them. You can do what you want with that, you're not supposed to look under the hood and figure out *how* the functions actually work.
> 5.2 YOU AGREE AND ACKNOWLEDGE THAT, ONCE A PRODUCT IS USED OR CONTROLLED BY OR THROUGH THE DIGITAL IMAGING SYSTEM, SUCH PRODUCT SHALL BE OUT OF SUCH MANUFACTURER-WARRANTY WITH RESPECT TO THE PRODUCT AS SEPARATELY SPECIFIED BY FUJIFILM, FUJIFILM’S AFFILIATES, OR THEIR BUSINESS PARTNERS.
Brutal. Consumer protections are lagging badly behind in the software era. It's bad enough that commercial software has broad disclaimers against ensuring any kind of functionality, but this stuff is starting to creep into hardware too. I think right-to-repair is a good start.
Even in consumer places like the US, this is generally illegal.
They would not be able to refuse warranty service without showing that your use of the SDK was the reason the camera failed (and the burden would be on them).
IE they can't say "Yes, the lens popped out because it was defective, but you used the SDK so tough crap"
Funnily I had exactly this happen with HTC One - yes, your phone camera has degraded inside a warranty period and all photos have purple fade, but since you unlocked the bootloader, you're out of luck, bye.
Is that even legal? It seems similar to the "warranty void" stickers which are nothing more than an illegal scare tactic that many individuals are conned into believing.
It's not just a scare tactic, it's how these companies operate. They will illegally refuse to service products they have an obligation to. Until there are massive class action lawsuits, this isn't changing.
Even if it's illegal it doesn't override user protection laws, so the statement has no effect and they'd need to prove your SDK usage caused an issue with the product to legally deny warranty.
No, I don’t think that’s how that works. Your contracts with your customers is under the jurisdiction of where your customers live, not where your company is headquartered. It would be way too easy to side step any law they wished that way.
Plus, must camera manufacturers sell through an american subsidiary. I know thats how Canon works.
I think it's totally valid to void warranty when customers modify product software. If users do things like disable temperature limits and mess up their camera, then I see no reason why the company (and be extension, other customers) should foot the bill.
Giving away the SDK, regardless of warranty revocation, is a step ahead of most camera manufacturers.
If I swap out my car's engine with a more powerful one and screw up the drivetrain will warranty cover it? If I load broken firmware onto my device that screws it up, why should the company be on the hook? Replacing firmware is no different than replacing any other component.
What countries force companies to provide warranty when users load faulty firmware onto devices?
In the US, car manufacturers are required to honor the warranty for the rest of the car after you swap the engine unless they can prove your engine swap caused the failure they don't want to repair. They will probably have little difficulty proving that for a scenario like a more powerful engine breaking a transmission. They'd have a much harder time claiming it caused the heated seats to stop working.
This SDK seems to be for PC-based remote control apps, not camera firmware. A well-designed camera firmware would not accept remote control commands that exceed the hardware's safety limits.
That's not the problem. The problem here is that Fuji appears to be claiming that any use of the SDK voids the warranty entirely, regardless of the defect. t would be like if you swapped out your car's engine with a more powerful one, and then, from a completely unrelated fault, its navigation system stops working.
In the US, my understanding is that this is explicitly not legal, per the Magnuson–Moss Warranty Act. FujiFilm can choose not to offer a warranty at all, but if they offer one, then it must cover defects on modified devices unless they can show that the modification caused or contributed to the defect.
In the EU, it is my understanding that it is legal to have a guarantee with terms like these. However, regardless of any guarantee the manufacturer may offer, there is a statutory guarantee in the EU for most products, which completely ignores the terms that the manufacturer might prefer. This usually ends up being weaker than Magnuson–Moss in terms of duration and modifications. But it usually means that for six months, the seller must prove that the fault with the product was caused by the consumer, and for two years, if you can show that the problem is from a defect with the device originally and not from you, then you can still get repairs, replacement, or a refund.
The short answer is: The warranty must cover damage not caused by your modification.
There are no countries i'm aware of that require you warranty damage caused by user modification.
Lots of countries require that you do not void the entire warranty, or refuse service, of any damage not caused by the modification, and generally the manufacturer has to show the damage was caused by the modification if they want to refuse service.
In this case, Fuji is trying to void the entire warranty. That is not legal in a lot of countries.
And isn't that normal? If you remap your ECU to use a different fuel mixture that voids the warranty right? That's what google results overwhelmingly say. And it makes perfect sense. Users might alter the firmware to run at a suboptimal setting that increases wear. Would you expect a manufacturer to honor warranty if you bolted on a turbocharger?
Hardware should be designed to be resilient to broken software to whatever degree possible.
And then still, warranty should cover defects in the face of modified software.
The SDK is not some hack downloaded from some shady website. It’s not a third-party unauthorized tool. This isn’t like, “I transformed my Tesla into an ICE car and then asked them to fix it.” It’s like, “I paired my phone via Bluetooth to the entertainment system and now they won’t fix my defective AC.”
Yes it’s hard to prove that hardware wasn’t broken by broken, unauthorized software modifications. Is there even a small amount of evidence that the warranty burden caused by software modifications is significant? Many stores are happy to cover occasional consumer error even if they’re not actually liable to, and that is SURELY more common than firmware modifications.
Not to mention the directions this could go into. Oh, malware exploited our phones and then modified the system firmware? Sorry, your warranty is void because you ran unofficial firmware, goodbye.
(Obviously, and especially in the last case, if you do break your device on your own, or someone else does, then of course manufacturer warranties do not cover that. That’s a whole different wheelhouse. But your warranty should not be entirely void over software. This is the same as those technically-not-legally-binding “warranty void if removed” stickers everyone unfortunately tolerates.)
wouldnt shutter control give the possibility of the image sensor overheating from extended exposures? I could absolutely be talking out of my ass but I thought I remembered that being a risk when I flashed ML to my Canon for star photos.
The worst I can thing of is extra noise from the heat build up from the sensor being energized for extended period. This is one of the many reasons that image stacking is so advantageous. Cold winter nights imaging Orion is probably not going to notice it nearly as much as those hot summer nights trying to image Milky Way. (I'm hoping to take my camera cooler out for a spin this summer. Just a modified pelican case with insulation and ice chest freezer packs. lo-tech)
Basically every camera I have had has a "bulb", which is pretty much as-long-as-you-want exposure. Never heard of sensor overheating even after hours of exposure.
Overheating is more of an issue for the image processor, at high frame rates. During bulb mode, the sensor is on for a long time but it's only one frame being handled by the image processor.
There are a lot of changeable settings listed in those header files, chances are some combination of settings or other highly-tuned SDK usage could put the camera to work and potentially cause it to overheat (eg. forcing a specific shutter speed while also capping the movie shutter speed, perhaps) since they're not testing the use cases you could theoretically enable via the SDK.
Regardless of their written policy or silly warranty void stickers, the law dictates the warranty still covers all components not modified or damaged by the consumer. You might have to fight in court, but thats the law.
This SDK only works on the top end Fuji's, the cheapest one supported starts at £850 (body only)
Fuji has famously terrible app support, its a nightmare to set up and cuts out constantly, transferring images over wifi is slow and unreliable to the point of it being useless, the remote shutter is unreliable and doesnt have any of the extremely simple to program features that intervalometer's have. You can't shoot tethered unless you have one of the above very expensive cameras.
The whole software ecosystem around cameras is awful, I would love to see some open source community initiatives to be able to control these cameras and extend their functionality but I haven't seen much of that in the photography community.
A typical high end camera product would starts at $2000, and nowadays more often than not is $3000+.
A quick search shows the top end of Fuji X mount is $2000+.
And that’s not even the top end of Fuji’s, which goes to the medium format GFX mount.
For your other points, I know you’re talking about app, but Fiji has been famous about their software support in terms of how long they continue to update their firmware. They even market it Kaizen. And it is an objective truth that you can verify by comparing to how often other brands upgrade their firmware (Sony is not bad but still not as good.)
There exists open source softwares on camera, just may be not Fuji (I don’t know.) If you want open source softwares running on camera which significantly increases its capability, try Canon’s. That one is the most mature.
I haven’t tried Magic Lantern yet, but I have been reasonably happy with Canon’s remote app. It has been reliable so far, with the only downside being that it doesn’t offer GPS tagging for my camera (EOS 80D)
The lack of an intervalometer in ANY camera today is an insufferable insult.
Not to mention that the assertion in the title of this post is wrong, at least in the USA. We have a federal law called the Magnuson-Moss Warranty Act that makes it illegal to void the warranty of a product simply because the user modified it.
Canon cameras have enjoyed some fairly active open-source/hacker support. Check out Magic Lantern and CHDK (I can't tell if that one's still maintained).
Exactly, this part of the agreement may not void the warranty. Just like stickers on the outside of a product that say "Warranty void if broken" don't void the warranty.
In fact, the Magnusson-Moss act makes it illegal to void a warranty even for 3rd party, aftermarket modifications to a product, unless it can be shown that the aftermarket modification is the cause of or contributed to the warranty claim.
So even if you had some random black box that you plugged into your cameras USB port, and it would send all sorts of wild commands to the camera, that would not void your warranty unless the black box was actually responsible for the damage to the camera.
The thing is, if the image sensor overheats with this supposed camera stresser, how would they prove it? Do they start to keep tons of logs about API usage and deny a warranty claim if that log has been wiped?
For those looking to use something in between some of the horrible official camera apps and implementing something with this SDK, Cascable is really quite nice. I find it well worth the subscription.
Before the official SDK came out, I tried using this project that was working on reverse engineering the protocol for Fuji cameras:
Camera manufacturers really seem to try to shoot themselves in the foot as much as possible. They are putting on something interesting and immediately kill it for braid use. Nobody is going to publish software based on the SDK. At least nobody who doesn’t want the threat of lawsuits hanging over them.
They also make medium format mirrorless cameras, which are a great way to feel superior to all the people who think "DSLR" is what you call a high-end digital camera.
I can't quite bring myself to spend the money to get a GFX 100S though.
Neither of those have IBIS (stabilization) which is a big deal if you're shooting such large images handheld. Fine in bright daylight or on a tripod though.
It would be great to have on Fuji cameras something like Magic Lantern on Canon's. Technically camera HW is capable of much more than manufacturer allow to do with software.
They usually support cameras with updates for 2 years and and then nothing. I understand that it is more profitable to make new cameras but it is not sustainable and eventually all consumer camera manufacturer will have to change their approach, because this industry slowly dying in consumer area. And it is not necessary because of smartphones but also because cameras since circa 2014 are good enough to keep them until die, not to switch every year.
I'm using Fuji cameras for pro work over 5 years now and I still mostly use X-T2 and x100F. Those are most reliable cameras I have. Very solid construction, "made in Japan". X-T3 feels very plasticky. Same for X-T4.
I have an XE 4 and I also investigated the possibility but they don't even provide headers for all the models. I would have to buy one of the few supported models to be able to play with the SDK.
They are missing a big oportunity and whoever wakes up first may get a nice boost from computational photography afficionados as well as many specialized fields.
I understand that they are trying to save development time by not building the necessary safeguards and I wish they published some less invasive way to communicate with the cameras such as over bluetooth or Wifi which many cameras already support.
An interesting question here is: How would they know that you used the SDK?
Does the camera have non-volatile memory for saving that piece of info? Assuming that it does, how can they make that bit tamper-proof?
Not that tamper-proofing is undoable, but it would require a lot of expensive engineering, just to save them from replacing a few dozens of cameras that presumably may break because of incorrect use of the SDK.
I have no idea what the exact hardware inside of the camera is, but almost every microcontroller has something like eFuses or one time programmable memory in this day and age. Not a lot of expensive engineering required, just a few hours of software development for the camera firmware and SDK developers. It'll be good enough for most warranty cases you can now hand wave away.
> 5.3 BEFORE SELLING, LICENSING, PROVIDING OR DISTRIBUTING THE DIGITAL IMAGING SYSTEM TO YOUR CUSTOMER (IF ANY), YOU SHALL EXPLAIN AND MAKE SUCH CUSTOMER FULLY UNDERSTAND THE WARRANTY-EXCEPTION SET FORTH IN THE PRECEDING PARAGRAPH.
this is a b2b2c term -- we need better tech for capturing consent up the chain and for surfacing contract terms to downstream clients
(notwithstanding the fact that in this case, it's 65% bullshit that the warranty is voided and 110% bullshit that fuji expects downstream consent to be captured)
Of course it isn't good that the warranty is being voided, but as a matter of contract this particular clause seems very logical. For the consumer it is good to know when you are being provided a third-party service/app that could void a warranty, and a clause like this makes the third-party provider liable for non-disclosure of the risks.
but they're not being provided a 3rd-party app that voids a warranty
they're getting a 1st party app that (if you think this contract is enforceable) voids the warranty
in practice, this whole page of products https://fujifilm-x.com/en-us/products/software probably (I'm guessing) uses the sdk, is probably advertised as part of the product's value, and doesn't say anything about warranty
if fuji finds out you used the camera with photoshop, then uses that to reject a subsequent repair (related or unrelated to sdk), this seems like a reasonable case for false advertising and a refund
I have a Fujifilm XPro3. My favorite camera of all time. But I would trade it in for a camera with equivalent specs that runs a proper operating system and supports app development.
Cameras are so far behind smartphones in terms of their software that it has become embarrassing. Paying $2000+ for a camera, only to find out your smartphone does a better job of autofocusing and handling noise is just annoying.
It would make their cameras much more flexible and useful, thus perhaps gaining some users that currently use smartphones where it seems there is greater control over and integration with the cameras. On the other side, if one can implement in software what the producer doesn't want to implement in firmware, they might miss some future upgrade sales...
I am currently thinking on buying a FujiFilm X-T4, and I was pleased to see there is a SDK, but now, finding out that using the SDK is practically forbidden (until the warranty ends), it makes me stop and think about my decision... What could the SDK do to the camera so that it voids the warranty? (On the other hand, given the quality of camera brand produced software, I can imagine the quality of the code that went into it...) :)