I wanted to use my new Sony DSLR (a6700) in the same way as I use my server: by ssh'ing into it.
This is a one day hackaway helper built on Sony’s official Camera Remote SDK. It sort of mimics an ssh session by connecting to my Sony over Wi-Fi, listens for new photos or specific events... and runs scripts on them.
Thank you Sony, for not forgetting the Linux fan base.
And thank you ChatGPT for freshening up my c++ skills!
I wouldn't thank ChatGPT too enthusiastically. As always for LLMs, it has given you code that is rife with common pitfalls (because, after all, they massively plagiarize sources where people post poor code).
For examples: It does not follow the Linux rules for pathname separators, but mixes in Windows-isms. It doesn't properly check whether std::atomic<bool> is actually signal safe on the target architecture. Its unique filename generation has an all-too-common failure mode. It passes by reference only to then make local value copies anyway. It does not correctly follow the XDG Base Directory Specification.
Last time I hand started a c++ project was 10+ years ago so let's say it got the ball moving ;) Feel free to help cleanup a bit of my mess if you want, would love to work on this project together with others!
Wrong words are commonplace in English, perhaps my favourite being “modern art” referring to art from 100 years ago. Long story short: don’t worry about it.
- Canon has a REST API, and the most affordable API supporting cameras.
- Fujifilm has an API, but not REST based, but it goes all the way back to the X-T3. Unfortunately, using it voids your warranty if there is a warranty.
- Sony has an API as well but mostly newer cameras.
- Blackmagic (video cameras) has a REST API, but their most affordable API-supporting cameras are meant for studio use, which isn't ideal for general use.
I can't speak for other brands, but I started this project by digging into the LCD menu of my camera, discovering "auth", "user", "pass" and wanted to know what protocol they used to authenticate remote logins. That's when I discovered the camera just uses ssh-style auth.
As a part time sysadmin, it gave me the idea to try to "log into" the camera and here we are.
This doesn't actually use ssh at all right? By ssh-style auth you just mean a username and password? Seems to work great for the intended use case regardless !
> - Fujifilm has an API, but not REST based, but it goes all the way back to the X-T3. Unfortunately, using it voids your warranty if there is a warranty.
It seems most of the newer cameras (Z6 iii, Z5 ii, Z50 ii) and the Z9 support „Wi-Fi STA“ mode, as Nikon calls it. All other models apparently only do „AP“ mode, where the camera turns into an access point - super annoying.
Curiously the Z8 (which is basically a Z9) and the Zf (which is basically a Z6 iii) don’t support STA.
AP mode ought to be faster and more reliable because the camera sends the signal directly to the receiving device instead of an external AP rebroadcasting it and halving the available bandwidth.
The problem is with the software. It disconnects and sends data incredibly slowly, orders of magnitude slower than what the hardware is capable of.
Transferring from my D7500 has to crash once the fist time every time when transferring over WiFi before it works. They said they knew about the bug like 5 years ago so I don’t think they are working on it.
The last two generations of Samsung NX cameras were built around Tizen Linux, and it was (and still is) easy to get a root shell on them. They still make great photos and you still can buy them used for a good price.
NX300/NX30/NX2000 had a read-only rootfs, but for NX500 and NX1 there was a persistent mod that extended camera functionality with a menu, and you can actually SSH into them and rsync your photos... while shooting!
Great to see another Samsung NX hacker in the wild! I'm in the process of developing a mod for my NX300 and NX30 (with the NX2000 likely compatible). It doesn't do anything yet, but I've got a lot of work done on hooking ARM code [0] and compiling modern C++ for the cameras.
Personally I think the NX300/30/2000 are the most hackable cameras ever made, even compared to the NX1/500. The read-only rootfs isn't really a barrier, since the software runs a shell script from the SD card on boot (or rather resume from hibernation, it's a pretty clever system). And unlike the newer models, they don't have an RTOS coprocessor, so everything is handled in the easier-to-modify Linux code. It's not a design decision I would have made, but it makes in-depths mods easier.
The older cameras are also easy to unbrick, since the bootloader files used for firmware flashing without a working OS were released in the FLOSS code dump. The availability of some C headers in that dump is the cherry on top.
I'll admit I'd still rather have an NX500, I just bought the NX300 because I'm cheap :)
Regarding the RTOS, I took my NX300 from the shelf some weeks ago to make a few shots for the live demo at https://programm.froscon.org/froscon2025/talk/fc37ae17-9264-... and OH MY FSCKING GOD IT'S SLOW! I made a burst shot of a model train approaching, and the camera was busy processing it for multiple minutes. The NX500 is lightning fast in comparison, and the NX1 is even snappier.
So what do you plan to do with the ARM hook? I've poked at different places of di-camera-binary, but never at the processing pipeline, and there are soooo many things to reverse-engineer, and I'm but one person!
The possibilities are endless, so I need to make sure not to get lost in them and actually get something done :) I have a shortlist of changes to make, from surface-level to harder things:
- Allow configuring the controls. For example, the multi-purpose "focus" ring is great, but is severely hampered by having to press the "iFn" button every time.
- Add bulk upload of photos to Immich (though that could just as easily be an external script).
- Write custom widgets for the LV view, like a RAW histogram or time display. Also hide the bottom buttons that have already burned into my screen.
- Allow full electronic shutter (I already had to change this camera's shutter once).
- Add highlight metering, or rewrite the autoexposure entirely.
- Support outputting raw video.
- Tone down the denoising on out-of-camera JPEGs.
- Play with custom sensor crops, line skipping and other things to get zoomed in videos.
I had the NX1 with all the premium lenses and some photos still seem to be better than what my Sony A7-M4 shoots. But no 10bit 4:2:2 for video and no real flat profile was a bummer. I loved the persistent mod though. Sold all NX1 gear years ago, moved to a Sony A7-M3 and then A7-M4. Full Frame has some great benefits.
Yes, aware of that, and nothing recent works with it, the last progress sadly was years ago.
I guess DMCA/Sony Lawyers and the relatively low market share for expensive cameras is the main reason why a PlayStation, an iPhone or a Nintendo Jailbreak is more appealing to reverse engineers than a Sony Camera Jailbreak.
Actually, half of the problem is vertical integration inside Sony cameras. It's all Sony from sensors to DSPs, and everything is designed and built by them.
The current firmware looks like a embedded Linux system designed for fast boot and is largely immutable, so the thing is pretty tightly secured down. You can put the board to flash mode and update the firmware, but that's all apparently.
Someone over DPReview was taking deltas of the file trees between firmware update packages to guess what has been updated, but going one step further was nigh impossible.
Sony doesn't even bin the DSPs from model to model, but create model-specific ones with different model numbers, and solder DRAM on top of them for latency and signal quality, so the cameras are complete black boxes.
The only missing thing is a complete epoxy pour over the board, but that thing gets hot and needs the case as a heat-sink, so it's not possible at this stage.
The other half of the problem is what to gain from a root shell. You can't influence the stages of the image processing without a PhD in Sony DSP Reverse Engineering, and so what remains is probably hooking into the camera controls and injecting key events to re-invent time-lapse timers or bulb exposures, and removing the 30min video recording limit.
This is where the NX mod project arrived - additional hooks into the camera controls and a few changes to internal registers left over by Samsung engineers for debugging, like silent shutter or the 30min limit.
Sony's full frame machines are so customizable out of the box already, so you don't need anything to begin with, at least for normal photography needs. Maybe focus stacking, but it's a pure new procedure.
30 minute recording limit is already lifted and advanced time-lapse is introduced alongside mammal eye tracking with a firmware update by Sony, and you can customize anything sans preliminary image processing steps, and by customization I mean the parameters of the algorithms or algorithms themselves.
Moreover, Sony's full-frame systems are already distributed systems to begin with. There are at least two DSPs running asynchronously during focus and image capture, so there may be no pathways to influence the DSPs significantly after they boot up, even.
Personally I wouldn't muck with a system designed to do image processing 30FPS even before taking a photo (A7-III) incl. face and eye tracking and focus correction without any hiccups to this day.
From what I understood, these cameras perform a nigh impossible dance within the limits of their hardware to maximize speed and reduce energy consumption. Who am I to disrespect them for doing that. Instead, I prefer to use the thing and get nice photos out of it.
Neat project, the one thing I still don't understand is how it's still so hard to wirelessly get photos on and off professional/prosumer cameras.
We had EyeFi cards back in the day, and I could configure them to (flakily, but given enough time, it worked) automatically upload RAW image files to a local FTP server while I was out shooting an event.
Years later, and a bunch of janky apps that mostly work with low-res JPEGs or if you fiddle with them, maybe RAW files, are the best that Canon, Nikon, and Sony have to offer first-party :(
My Sony a7iii can definitely upload to FTP by itself, JPEG and RAW. That is my primary means of getting images off of it. I would have appreciated if it did WebDAV though, then I could make it push to Nextcloud directly...
Believe it or not, but I'm old enough to have used Eye-Fi cards back in the day and its shitty performance inspired me to hack away on this project in the first place!
Aside if author is around: You may want to rename it to not include "Sony" in the name. If the project gets popular and catches their eye it might become a headache.
Sony doesnt make DSLR cameras, there is no 'reflex mirror'. These are mirrorless cameras, or Interchangeable Lens Cameras E-Mount (ICLE) as sony calls them
Legal reasons aside, it'd be nice if it eventually expands in scope to not be tied to original hardware. Eg. Kodi, nee XBMC, doesn't even mostly run on XBoxes anymore.
Heh, looks like the old OpenMemories hack [1] might actually have a successor now for modern cameras?
The old Sony lineup actually didn't just have a Linux kernel to run its base operating system, they actually included a bastardized Android layer on top of that so people could develop apps - but it died out pretty soon, so Sony removed it after the Mark 2 models and with it went the entrypoint for rooting.
Sony quietly removed the PAL/NTSC switch on some recent FX3/J1 firmwares — a really user-hostile move for anyone trying to avoid lighting flicker or needing flexible frame rates. The only practical “fix” I see in the wild is paying grey-market sellers (using leaked service tools I presume) to flip the 'region blob' so the menu comes back.
Is sonshell likely to be a useful vector for a more freely available solution? Not sure what level of access it actually offers i.e. is firmware/policy blobs readable/manipulable, and can persistent changes be made?
I'm afraid the only thing I do is use the official SDK to wirelessly log in to the camera. No firmware hacking at all. That said, if the SDK offers a setting the LCD menu on the camera doesn't, it would be fairly trivial to change it, yes.
Very interesting project, I wish I had gone down this route instead of the undocumented hell of usb PTP with hundreds of edge/corner case work arounds.
The fact that USB ptp is some baseline is kind of exceedingly great, even if yeah in practice it'a a huge mess of vendor extensions tacked on. I like trying to have some collaboration & specs! It's a monster oh sure but gphoto2 probably wouldn't have come about, as a sick compendium of all camera backs & vendor extensions, if there wasn't a common thread, common binding for cameras! Once you go from USB to IP you're (generally) untethered unmoored from anything shared!
What's done here is super admirable & super neat. But it's even more spelunking into the unknown than USB ptp imo! Thankfully there's some pretty old school direct on-the-line protocols that are kinda just working!
It's interesting to me at least to navel gaze over. The attempt to have common tools versus the just doing whatever.
One of my favorite connectivity solutions ever was the Nvidia Shield Controller (2015). A wifi (wifi direct/wifi-p2p at that!) video gaming controller. With audio that uses ozproto's stack, a usb-over-ip setup! Something about just tunneling USB being conceptually easier to reason about & do than deciding what IP services to make for a controller is so elegant and neat and weird. https://github.com/devmapal/nvidia-shield-controller-driver
When reverse-engineering some of the Samsung NX camera firmware files, I found USB-PTP code that implements different custom remote commands <https://chaos.social/@ge0rg/114723076401717110> but I'm not deep enough into PTP to make sense of them.
Is there anywhere a group focusing on understanding and re-implementing custom PTP protocols?
It is surprising that after all these years, there is still no good way to transfer files between two devices over USB. MTP exists but it was never widely supported and it seems like even the support it did have is slowly rotting as the answer became just connect everything to cloud storage.
reMarkable tablets end up exposing a USB ethernet device with a /23 private subnet and listing an IP address to visit in a browser. It works much more reliably than it should.
Nice work! I've wanted something like this while shooting, since people want to see what the photos I'm taking look like and all the software I've tried seems kinda bad.
Does this work better than the built-in FTP client software in the cameras? I've been tempted to just run an FTP server on my ipad which automatically shows all uploaded photos.
Funny you ask, since the a6700 doesn't have ftp support and it mainly was the reason I started this app in the first place. Also, wiring into the command structure with little shell callbacks offers me a LOT more flexibility than initially thought.
What a weird choice! An FTP client implementation is tiny.
I guess they figure FTP uploads are mostly used for professional sports photography, and they don't think people will buy the a6700 for that. (Or they don't want people buying the a6700 for that sort of professional use.)
Nice work in any case. My cameras have FTP, but using sony's remote protocol seems like a lot more fun. Its probably more reliable, too. (And I wouldn't be surprised if you can do more advanced stuff with it, like download low resolution proxies before downloading the high res images).
I wish my Olympus had something like this. They are considerably more customer hostile than other brands in both software and accessories. The app for those cameras is not even laughable; it's just depressing. And it can't be tethered to computers like every other camera system. Sigh.
Which Olympus is that? My OM1 can be tethered. I tried shooting with the camera connected over USB to a Windows computer, and it worked perfectly.
It also claims it's able to do the same via wifi when you connect it to an access point (instead of its integrated AP mode). I don't really have a use for this functionality, so I didn't bother to type my wifi password on the camera to try it out, so I can't comment on how well it works.
I've just tried this with darktable/Linux, and it also seems to work. It's somewhat slower than with the Olympus software under Windows, but I can change random parameters, such as shutter speed, aperture, and white balance. I can move the focus manually, which will trigger the zoom-in helper (it's how the camera is configured to behave when manipulating it directly). Taking a picture copies both JPG and RAW files (camera is setup to capture both) instantly.
Edit: on an iPhone, I can use PhotoSync instead of the OI Share app to retrieve pictures over Wi-Fi. It's quite slow, though. My iPhone is too old to support direct USB-C connections, so I haven't tried that, though I intend to try iy tomorrow with a friend's phone.
Ooo, I'll need to look into this again. I worked with the devs from Darktable / gphoto a few years ago trying to get it to work and both sides eventually gave up because the output from the camera was just so far from any spec.
I've got a EM1mk2. I just tried it again with Darktable on Linux and it didn't immediately work. But now that I know it's supposedly possible I can look into permission issues or the like. I'll go through Darktables' troubleshooting steps for this.
Does the camera actually support tethering? I also have a pen-f, and I don't have such an option when I connect it to a computer. I can only do it via the phone app, and it never worked well. The om1 works better with the app.
Apparently, when connecting to an external AP, it supports WPS, both PIN and button, instead of typing the full password. My AP doesn't support any form of WPS and I mistyped my password. That's five minutes of my life I won't get back...
Interestingly, the transfer from the camera seems slower with OM Capture than with Darktable, but it can configure basically all the camera's settings, including the High-Res, HDR bracketing, etc. It can also tell the camera to not save the files on its card (or configure which format goes on which card).
Yeah, it supports tethering. After fiddling with it for a moment (and reading the Darktable docs to discover I have to click the Mount Camera button first), I've got some semblance of tethering working. It's a bit slow and I can't figure out how to focus yet, but it can capture an image. This is pretty awesome.
So... if you have guests on your network or are otherwise connected to a network with lots of people on it, can they just grab all your photos this way?
The app was built to suit my needs with my Sony a6700 but it uses the official SDK. So it should theoretically support all the cameras the SDK supports.
the A7R has a background FTP function but the problem is Wifi is deadly unreliable and low bandwidth for transferring huge files. for camera automation I've found it much easier to write to SD card then handle import in batches
Multi thousand dollar pro camera and they can’t figure out the WiFi. Sony’s unwillingness to provide any material firmware updates is so disappointing.
Unfortunately it isn't just Sony, every Canon I've ever owned has had trash wifi. It must be one of those teams in an org that's an afterthought of an afterthought.
People think all professional cameras are called "SLRs".
A rangefinder is a higher quality camera than an SLR ever was and a full frame mirrorless probably has better quality than a DSLR, in both cases because it's easier to design lenses for them. A medium format camera can be better than all of those.
A medium format camera can also be a DSLR. An a6700 or an A7 is not a rangefinder, it's a mirrorless camera. You're mixing up characteristics.
DSLR means: it's digital, it uses one lens, and the visor image comes from the same lens that goes to the film, but reflected on a mirror to your eye (probably through a pentaprism, but that can vary), so you can see the same image that will be captured in the sensor.
A rangefinder is a camera where you look... through a rangefinder. It's a visor independent of the film/sensor, like a classic Leica. That means that the image you see is not exactly the same that will reach the sensor/film, as it will go through a different optical system. There are digital rangefinders like the M series Leicas.
Mirrorless means, it doesn't have a mirror to send the image to the visor. The typical mirrorless cameras nowadays get the visor image directly from the sensor, you don't look through a rangefinder. A rangefinder is mirrorless, but not every mirrorless is a rangefinder. Most digital mirrorless cameras aren't rangefinders.
A rangefinder (or mirrorless) camera is not inherently better than a DSLR. Mirrorless cameras can have simpler optical designs that achieve more quality easier, but there are better and worse cameras in both sides.
I went the extra step to clear those terms for anybody that could read it, just in case anybody is interested.
You said:
- A rangefinder is a higher quality camera than an SLR ever was
- a full frame mirrorless probably has better quality than a DSLR
- A medium format camera can be better than all of those
I say you're mixing stuff because:
- rangefinder only means it has a rangefinder. There are Yashica Electro, Argus C3, and there are Leicas. Most rangefinders are medium/low quality
- well nowadays, maybe, but not necessarily. But we can generalize a bit in that case
- A medium format camera can be mirrorless, DSLR, rangefinder... so it can be in any of those groups, so we cannot compare it just like that
>A rangefinder is a higher quality camera than an SLR ever was
This does not mean anything at all. The comparison is total nonsense.
>and a full frame mirrorless probably has better quality than a DSLR
No. DSLR and Mirrorless camera differ how the viewfinder works. Generally Mirrorless cameras are newer, but ranking them for quality is totally nonsensical. This is independent of the size of the sensor.
>A medium format camera can be better than all of those.
You are comparing totally different things. A full frame Camera can be Mirrorless or a DSLR. There is no comparison to be made here. You are totally confused about technology and terminology.
A camera is a product with multiple components. Mirrorless camera designs can have smaller and higher quality lenses for the same price because they don't need to accommodate the SLR mirror behind the lens.
I don't think image quality is the end all be all of a camera, but is what amateurs think the purpose of an expensive camera is.
I think it's better to steelman rather than assert ignorance on the part of the person you're replying to.
It is true that people these days associate the DSLR form-factor with professional photography, despite the heavy use of rangefingers by those such as Robert Capa etc not that long ago. And it is also true that both rangefinders and mirrorless ILCs avoid the need for retrofocus designs which in theory should make for higher-quality lenses at the same weight, or similar quality and a lower weight.
As for "better" this is often a matter of preference and it's okay for people to have different preferences. For me personally, I wish there was more experimentation in ILC form factor, it seems most (with a few notable exceptions) ape the pentaprism hump even if they don't contain one.
I think it's easy to see what they mean, even if you don't agree with them. I think it puts too much emphasis on glass as there's so much more that goes into getting a shot. I do pick up my old film cameras every now and then for enjoyment, but if I have to get a shot, I'm always taking the newest thing I have. It's hard to beat multiple stops of stabilization in the lens and the body along with the black magic of modern sensors.
Not having a mirror is not the most important characteristic of the hardware for this project.
Being able to control it through an API is. What happens after you trigger the shutter is out of scope. Speaking of shutter buttons, a bunch of new cameras don’t have shutters but the button is still called a shutter button.
While I mostly agree its a matter of jargon, the original author never calls their camera a DSLR.
Also yes while yes many cameras do not have moving shutters, they still operate with an electronic shutter which just like a moving one does have various limitations.
I'd argue though to many a photographer, calling any ILC or sufficiently costly camera a DSLR is akin to a post calling an android phone a linux phone. To the layperson the nuance between ubuntu's kernel or a pixel's doesnt matter to them, however to the intended audiences it sure does.
To be pedantic for the people still reading this, curious enough to go further without falling down a Wikipedia rabbit hole.
The reflex mirror in a (D)SLR directs the image up through the viewfinder prism to the eyepiece. This mirror flips upwards just before the shutter opens. This mechanic action has a decent bit of inertia and can cause blurring in some extreme cases.
Mirrorless refers to digital cameras where the sensor operates the digital viewfinder, so like an SLR “you get what you see”. For rangefinders and TLRs, your view is offset from the picture lens, so if you’re really trying to nail a composition and not “fix it in post” SLRs and mirrorless offer an advantage, which is part of why they became so predominant.
No. When I see a6700 and DSLR used in the same sentence, I have to question whether that is a misunderstanding on the author's side, whether it's actually for Sony a6700 or some other camera, or if anything in the repo makes sense or if the author knows what they are doing. This erodes confidence if the author cannot even get the very basics right.
DLSR stands for Digital Single-Lens Reflex. An a6700 is indeed digital, has a single lens, and is undoubtedly a camera. All it’s missing is a reflex mechanism. So I’d say that in four out of five ways, it is indeed a DSLR camera.
No - it's "single-lens reflex", a single attribute without comma. That is, a mirror redirecting light from a single lens to different targets (viewfinder and film/sensor).
If "four out of five words" was good enough, then an analogue film camera is also a DSLR - it's only missing the "digital" part after all. Seahorse and racehorse is also just one word apart, so basically the same, right?
The digital camera was invented in 1968, the first auto-focusing SLR is from 1978.
Auto-exposure came a few years before auto focus, but not by much as it still required not only light metering but also multiple mechanical couplings to the lens.
Such cameras (like the famous Canon A-1) were never refered to as "digital cameras", and SLR was used to distinguish from rangefinders primarily.
DSLR describes the basic operation mechanism of the camera. The A6700 does not have that mechanism, it has no optical viewfinder.
DSLR is an obsolete technology, just like your phone modern cameras can use their digital sensors to give a preview of the actual image on the sensor. Saying that some camera is a DSLR means something, namely that it uses an optical mechanism to project the light through the lense into a viewfinder. It is a technical term with a clear meaning, calling the A6700 a DSLR is wrong.
Sometimes four out of five doesn't cut it. Thats like claiming my car is an electric car because "they both have batteries and motors". Or like saying C is a functional programming language because its a programming language that "has functions".
The defining characteristic of SLR and DSLR cameras is the reflex mechanism, which is a giant mechanism inside the camera that sits in front of the film or sensor. The mechanism uses a mirror to allow the viewfinder to work. And the whole thing needs to physically flip out of the way when you press the shutter button to expose the film. But as a result, SLR / DSLR cameras are usually way bigger physically to make room for the mirror and the reflex mechanism.
Mirrorless cameras like the A6700 don't have this reflex mechanism, so they're not DSLR cameras. They're called mirrorless cameras. Same as the cameras in our phones.
I wanted to use my new Sony DSLR (a6700) in the same way as I use my server: by ssh'ing into it.
This is a one day hackaway helper built on Sony’s official Camera Remote SDK. It sort of mimics an ssh session by connecting to my Sony over Wi-Fi, listens for new photos or specific events... and runs scripts on them.
Thank you Sony, for not forgetting the Linux fan base. And thank you ChatGPT for freshening up my c++ skills!
I wouldn't thank ChatGPT too enthusiastically. As always for LLMs, it has given you code that is rife with common pitfalls (because, after all, they massively plagiarize sources where people post poor code).
For examples: It does not follow the Linux rules for pathname separators, but mixes in Windows-isms. It doesn't properly check whether std::atomic<bool> is actually signal safe on the target architecture. Its unique filename generation has an all-too-common failure mode. It passes by reference only to then make local value copies anyway. It does not correctly follow the XDG Base Directory Specification.
Last time I hand started a c++ project was 10+ years ago so let's say it got the ball moving ;) Feel free to help cleanup a bit of my mess if you want, would love to work on this project together with others!
Nitpick: that's a DSLM, or just "mirrorless" camera. There's no reflex mirror, so it's not a DSLR.
The more common initialism/abbreviation is MILC, or mirrorless interchangeable-lens camera.
I'm sad that Electronic Viewfinder, Interchangeable Lens (EVIL) didn't catch on
Wrong words are commonplace in English, perhaps my favourite being “modern art” referring to art from 100 years ago. Long story short: don’t worry about it.
Some stuff that could be improved with modern C++,
Instead of
Use the filesystem API, -- https://en.cppreference.com/w/cpp/filesystem.htmlty!
My recent research:
- Canon has a REST API, and the most affordable API supporting cameras.
- Fujifilm has an API, but not REST based, but it goes all the way back to the X-T3. Unfortunately, using it voids your warranty if there is a warranty.
- Sony has an API as well but mostly newer cameras.
- Blackmagic (video cameras) has a REST API, but their most affordable API-supporting cameras are meant for studio use, which isn't ideal for general use.
I can't speak for other brands, but I started this project by digging into the LCD menu of my camera, discovering "auth", "user", "pass" and wanted to know what protocol they used to authenticate remote logins. That's when I discovered the camera just uses ssh-style auth. As a part time sysadmin, it gave me the idea to try to "log into" the camera and here we are.
This doesn't actually use ssh at all right? By ssh-style auth you just mean a username and password? Seems to work great for the intended use case regardless !
I'm guessing, but AFAIK, the camera runs some sort of sshd demon you log into, so I wouldn't be surprised it really does use ssh under the hood.
> - Fujifilm has an API, but not REST based, but it goes all the way back to the X-T3. Unfortunately, using it voids your warranty if there is a warranty.
The Magnuson-Moss Warranty Act would like a word.
My Pentax KS-2 (2015) has a REST API.
https://sourceforge.net/p/pentaxks2wifiremote/wiki/K-S2%20We...
I read the first item as:
> ... and (the most affordable API) supporting cameras
when it was (probably?) meant as:
> ... and the most affordable (API supporting cameras)
any info about Nikon?
Nikon hasn't yet figured out how WiFi works, let alone a REST API!
They're firmly stuck in the early 1990s in terms of system software.
It seems most of the newer cameras (Z6 iii, Z5 ii, Z50 ii) and the Z9 support „Wi-Fi STA“ mode, as Nikon calls it. All other models apparently only do „AP“ mode, where the camera turns into an access point - super annoying.
Curiously the Z8 (which is basically a Z9) and the Zf (which is basically a Z6 iii) don’t support STA.
AP mode ought to be faster and more reliable because the camera sends the signal directly to the receiving device instead of an external AP rebroadcasting it and halving the available bandwidth.
The problem is with the software. It disconnects and sends data incredibly slowly, orders of magnitude slower than what the hardware is capable of.
Transferring from my D7500 has to crash once the fist time every time when transferring over WiFi before it works. They said they knew about the bug like 5 years ago so I don’t think they are working on it.
Reading the title, I thought: finally someone rooted/jailbroke sony cameras.
On Canon you can run Magic Lantern, an extensive mod that adds many features to Canon cameras.
Even Samsung N1 had SD Card loadable mods before they moved away from the camera market.
Rooting sony seems impossible, I never saw someone Working on it Since their Fullframe lineup launched.
The last two generations of Samsung NX cameras were built around Tizen Linux, and it was (and still is) easy to get a root shell on them. They still make great photos and you still can buy them used for a good price.
NX300/NX30/NX2000 had a read-only rootfs, but for NX500 and NX1 there was a persistent mod that extended camera functionality with a menu, and you can actually SSH into them and rsync your photos... while shooting!
Background: I've recently taken over maintenance of the NX-KS mod at https://github.com/ge0rg/nx-ks-mod
Great to see another Samsung NX hacker in the wild! I'm in the process of developing a mod for my NX300 and NX30 (with the NX2000 likely compatible). It doesn't do anything yet, but I've got a lot of work done on hooking ARM code [0] and compiling modern C++ for the cameras.
Personally I think the NX300/30/2000 are the most hackable cameras ever made, even compared to the NX1/500. The read-only rootfs isn't really a barrier, since the software runs a shell script from the SD card on boot (or rather resume from hibernation, it's a pretty clever system). And unlike the newer models, they don't have an RTOS coprocessor, so everything is handled in the easier-to-modify Linux code. It's not a design decision I would have made, but it makes in-depths mods easier.
The older cameras are also easy to unbrick, since the bootloader files used for firmware flashing without a working OS were released in the FLOSS code dump. The availability of some C headers in that dump is the cherry on top.
I'll admit I'd still rather have an NX500, I just bought the NX300 because I'm cheap :)
[0]: https://gitlab.com/dvdkon/pahil
Yeah, I've documented a thing or two about the NX series on https://op-co.de/blog/tags/samsung-nx/
Regarding the RTOS, I took my NX300 from the shelf some weeks ago to make a few shots for the live demo at https://programm.froscon.org/froscon2025/talk/fc37ae17-9264-... and OH MY FSCKING GOD IT'S SLOW! I made a burst shot of a model train approaching, and the camera was busy processing it for multiple minutes. The NX500 is lightning fast in comparison, and the NX1 is even snappier.
So what do you plan to do with the ARM hook? I've poked at different places of di-camera-binary, but never at the processing pipeline, and there are soooo many things to reverse-engineer, and I'm but one person!
The possibilities are endless, so I need to make sure not to get lost in them and actually get something done :) I have a shortlist of changes to make, from surface-level to harder things:
- Allow configuring the controls. For example, the multi-purpose "focus" ring is great, but is severely hampered by having to press the "iFn" button every time.
- Add bulk upload of photos to Immich (though that could just as easily be an external script).
- Write custom widgets for the LV view, like a RAW histogram or time display. Also hide the bottom buttons that have already burned into my screen.
- Allow full electronic shutter (I already had to change this camera's shutter once).
- Add highlight metering, or rewrite the autoexposure entirely.
- Support outputting raw video.
- Tone down the denoising on out-of-camera JPEGs.
- Play with custom sensor crops, line skipping and other things to get zoomed in videos.
I had the NX1 with all the premium lenses and some photos still seem to be better than what my Sony A7-M4 shoots. But no 10bit 4:2:2 for video and no real flat profile was a bummer. I loved the persistent mod though. Sold all NX1 gear years ago, moved to a Sony A7-M3 and then A7-M4. Full Frame has some great benefits.
> Rooting sony seems impossible, I never saw someone Working on it Since their Fullframe lineup launched.
On some cameras, including the older firmwares for the current cameras, https://github.com/ma1co/Sony-PMCA-RE gives you a root shell.
Yes, aware of that, and nothing recent works with it, the last progress sadly was years ago.
I guess DMCA/Sony Lawyers and the relatively low market share for expensive cameras is the main reason why a PlayStation, an iPhone or a Nintendo Jailbreak is more appealing to reverse engineers than a Sony Camera Jailbreak.
Actually, half of the problem is vertical integration inside Sony cameras. It's all Sony from sensors to DSPs, and everything is designed and built by them.
The current firmware looks like a embedded Linux system designed for fast boot and is largely immutable, so the thing is pretty tightly secured down. You can put the board to flash mode and update the firmware, but that's all apparently.
Someone over DPReview was taking deltas of the file trees between firmware update packages to guess what has been updated, but going one step further was nigh impossible.
Sony doesn't even bin the DSPs from model to model, but create model-specific ones with different model numbers, and solder DRAM on top of them for latency and signal quality, so the cameras are complete black boxes.
The only missing thing is a complete epoxy pour over the board, but that thing gets hot and needs the case as a heat-sink, so it's not possible at this stage.
The other half of the problem is what to gain from a root shell. You can't influence the stages of the image processing without a PhD in Sony DSP Reverse Engineering, and so what remains is probably hooking into the camera controls and injecting key events to re-invent time-lapse timers or bulb exposures, and removing the 30min video recording limit.
This is where the NX mod project arrived - additional hooks into the camera controls and a few changes to internal registers left over by Samsung engineers for debugging, like silent shutter or the 30min limit.
Sony's full frame machines are so customizable out of the box already, so you don't need anything to begin with, at least for normal photography needs. Maybe focus stacking, but it's a pure new procedure.
30 minute recording limit is already lifted and advanced time-lapse is introduced alongside mammal eye tracking with a firmware update by Sony, and you can customize anything sans preliminary image processing steps, and by customization I mean the parameters of the algorithms or algorithms themselves.
Moreover, Sony's full-frame systems are already distributed systems to begin with. There are at least two DSPs running asynchronously during focus and image capture, so there may be no pathways to influence the DSPs significantly after they boot up, even.
Personally I wouldn't muck with a system designed to do image processing 30FPS even before taking a photo (A7-III) incl. face and eye tracking and focus correction without any hiccups to this day.
From what I understood, these cameras perform a nigh impossible dance within the limits of their hardware to maximize speed and reduce energy consumption. Who am I to disrespect them for doing that. Instead, I prefer to use the thing and get nice photos out of it.
It works on the stock firmware of the FX30, which is relatively recent.
Neat project, the one thing I still don't understand is how it's still so hard to wirelessly get photos on and off professional/prosumer cameras.
We had EyeFi cards back in the day, and I could configure them to (flakily, but given enough time, it worked) automatically upload RAW image files to a local FTP server while I was out shooting an event.
Years later, and a bunch of janky apps that mostly work with low-res JPEGs or if you fiddle with them, maybe RAW files, are the best that Canon, Nikon, and Sony have to offer first-party :(
My Sony a7iii can definitely upload to FTP by itself, JPEG and RAW. That is my primary means of getting images off of it. I would have appreciated if it did WebDAV though, then I could make it push to Nextcloud directly...
It is a strange market. There are some apps that include support for specific DSLR models. This one supports specific Canon and Nikon models:
https://sparkosoft.com/sparkocam-features
Believe it or not, but I'm old enough to have used Eye-Fi cards back in the day and its shitty performance inspired me to hack away on this project in the first place!
Oh shit we're old now?
Aside if author is around: You may want to rename it to not include "Sony" in the name. If the project gets popular and catches their eye it might become a headache.
Suggestions: DShelLR, dshr, dslr-sh, camshell
Sony doesnt make DSLR cameras, there is no 'reflex mirror'. These are mirrorless cameras, or Interchangeable Lens Cameras E-Mount (ICLE) as sony calls them
Legal reasons aside, it'd be nice if it eventually expands in scope to not be tied to original hardware. Eg. Kodi, nee XBMC, doesn't even mostly run on XBoxes anymore.
It's late, but still up. Thanks for the heads up ;)
Done!
Nice: https://github.com/goudvuur/sonyshell now automatically redirects to https://github.com/goudvuur/sonshell . (Didn't know you could do that.)
Did you have to set it up? Or automatic when you rename?
that's a feature of github when renaming repos
Can it be "Sny" or "Slony" (Simpsons nod)? Keep a fragment in, please, for discoverabilities sake!
I know a genuine Magnetbox, Panaphonic, and Sorny when I see one.
Just list the devices it has been tested with in the readme.
I guess we will find out!
Heh, looks like the old OpenMemories hack [1] might actually have a successor now for modern cameras?
The old Sony lineup actually didn't just have a Linux kernel to run its base operating system, they actually included a bastardized Android layer on top of that so people could develop apps - but it died out pretty soon, so Sony removed it after the Mark 2 models and with it went the entrypoint for rooting.
[1] https://github.com/ma1co/OpenMemories-Framework/blob/master/...
Excited to see this develop.
Sony quietly removed the PAL/NTSC switch on some recent FX3/J1 firmwares — a really user-hostile move for anyone trying to avoid lighting flicker or needing flexible frame rates. The only practical “fix” I see in the wild is paying grey-market sellers (using leaked service tools I presume) to flip the 'region blob' so the menu comes back.
Is sonshell likely to be a useful vector for a more freely available solution? Not sure what level of access it actually offers i.e. is firmware/policy blobs readable/manipulable, and can persistent changes be made?
I'm afraid the only thing I do is use the official SDK to wirelessly log in to the camera. No firmware hacking at all. That said, if the SDK offers a setting the LCD menu on the camera doesn't, it would be fairly trivial to change it, yes.
When I read the first word of the title I immediately thought this was going to be about a new rootkit.
Sorry to disappoint you ;)
Very interesting project, I wish I had gone down this route instead of the undocumented hell of usb PTP with hundreds of edge/corner case work arounds.
The fact that USB ptp is some baseline is kind of exceedingly great, even if yeah in practice it'a a huge mess of vendor extensions tacked on. I like trying to have some collaboration & specs! It's a monster oh sure but gphoto2 probably wouldn't have come about, as a sick compendium of all camera backs & vendor extensions, if there wasn't a common thread, common binding for cameras! Once you go from USB to IP you're (generally) untethered unmoored from anything shared!
What's done here is super admirable & super neat. But it's even more spelunking into the unknown than USB ptp imo! Thankfully there's some pretty old school direct on-the-line protocols that are kinda just working!
It's interesting to me at least to navel gaze over. The attempt to have common tools versus the just doing whatever.
One of my favorite connectivity solutions ever was the Nvidia Shield Controller (2015). A wifi (wifi direct/wifi-p2p at that!) video gaming controller. With audio that uses ozproto's stack, a usb-over-ip setup! Something about just tunneling USB being conceptually easier to reason about & do than deciding what IP services to make for a controller is so elegant and neat and weird. https://github.com/devmapal/nvidia-shield-controller-driver
When reverse-engineering some of the Samsung NX camera firmware files, I found USB-PTP code that implements different custom remote commands <https://chaos.social/@ge0rg/114723076401717110> but I'm not deep enough into PTP to make sense of them.
Is there anywhere a group focusing on understanding and re-implementing custom PTP protocols?
It is surprising that after all these years, there is still no good way to transfer files between two devices over USB. MTP exists but it was never widely supported and it seems like even the support it did have is slowly rotting as the answer became just connect everything to cloud storage.
reMarkable tablets end up exposing a USB ethernet device with a /23 private subnet and listing an IP address to visit in a browser. It works much more reliably than it should.
Nice work! I've wanted something like this while shooting, since people want to see what the photos I'm taking look like and all the software I've tried seems kinda bad.
Does this work better than the built-in FTP client software in the cameras? I've been tempted to just run an FTP server on my ipad which automatically shows all uploaded photos.
Funny you ask, since the a6700 doesn't have ftp support and it mainly was the reason I started this app in the first place. Also, wiring into the command structure with little shell callbacks offers me a LOT more flexibility than initially thought.
What a weird choice! An FTP client implementation is tiny.
I guess they figure FTP uploads are mostly used for professional sports photography, and they don't think people will buy the a6700 for that. (Or they don't want people buying the a6700 for that sort of professional use.)
Nice work in any case. My cameras have FTP, but using sony's remote protocol seems like a lot more fun. Its probably more reliable, too. (And I wouldn't be surprised if you can do more advanced stuff with it, like download low resolution proxies before downloading the high res images).
Can you control the camera via script/CLI? Things like releasing the shutter, focus, apeture, etc?
It's not implemented yet, but fairly easy to add, yes.
Already patched this in, I'll test it tomorrow :)
I "only" have a A6000, any idea if it works with that camera as well?
I wish my Olympus had something like this. They are considerably more customer hostile than other brands in both software and accessories. The app for those cameras is not even laughable; it's just depressing. And it can't be tethered to computers like every other camera system. Sigh.
Which Olympus is that? My OM1 can be tethered. I tried shooting with the camera connected over USB to a Windows computer, and it worked perfectly.
It also claims it's able to do the same via wifi when you connect it to an access point (instead of its integrated AP mode). I don't really have a use for this functionality, so I didn't bother to type my wifi password on the camera to try it out, so I can't comment on how well it works.
I've just tried this with darktable/Linux, and it also seems to work. It's somewhat slower than with the Olympus software under Windows, but I can change random parameters, such as shutter speed, aperture, and white balance. I can move the focus manually, which will trigger the zoom-in helper (it's how the camera is configured to behave when manipulating it directly). Taking a picture copies both JPG and RAW files (camera is setup to capture both) instantly.
Edit: on an iPhone, I can use PhotoSync instead of the OI Share app to retrieve pictures over Wi-Fi. It's quite slow, though. My iPhone is too old to support direct USB-C connections, so I haven't tried that, though I intend to try iy tomorrow with a friend's phone.
Ooo, I'll need to look into this again. I worked with the devs from Darktable / gphoto a few years ago trying to get it to work and both sides eventually gave up because the output from the camera was just so far from any spec.
I've got a EM1mk2. I just tried it again with Darktable on Linux and it didn't immediately work. But now that I know it's supposedly possible I can look into permission issues or the like. I'll go through Darktables' troubleshooting steps for this.
Does the camera actually support tethering? I also have a pen-f, and I don't have such an option when I connect it to a computer. I can only do it via the phone app, and it never worked well. The om1 works better with the app.
Apparently, when connecting to an external AP, it supports WPS, both PIN and button, instead of typing the full password. My AP doesn't support any form of WPS and I mistyped my password. That's five minutes of my life I won't get back...
Interestingly, the transfer from the camera seems slower with OM Capture than with Darktable, but it can configure basically all the camera's settings, including the High-Res, HDR bracketing, etc. It can also tell the camera to not save the files on its card (or configure which format goes on which card).
Yeah, it supports tethering. After fiddling with it for a moment (and reading the Darktable docs to discover I have to click the Mount Camera button first), I've got some semblance of tethering working. It's a bit slow and I can't figure out how to focus yet, but it can capture an image. This is pretty awesome.
Thanks for the heads up about this!
So... if you have guests on your network or are otherwise connected to a network with lots of people on it, can they just grab all your photos this way?
As of now, yes, but luckily auth support is on my todo list SOON ;)
Why change the title from Sony camera to Sony DSLR when the repository is specifically targeting Sony mirrorless cameras, not DSLRs...
The app was built to suit my needs with my Sony a6700 but it uses the official SDK. So it should theoretically support all the cameras the SDK supports.
The SDK does not support any DSLR's, and Sony announced its last DSLR camera 10 years ago.
the A7R has a background FTP function but the problem is Wifi is deadly unreliable and low bandwidth for transferring huge files. for camera automation I've found it much easier to write to SD card then handle import in batches
Multi thousand dollar pro camera and they can’t figure out the WiFi. Sony’s unwillingness to provide any material firmware updates is so disappointing.
Unfortunately it isn't just Sony, every Canon I've ever owned has had trash wifi. It must be one of those teams in an org that's an afterthought of an afterthought.
Didn't know these run Linux
[dead]
My trust in a project which can not identify the most important characteristic of the hardware used is pretty low.
The A6700 is not, in any way, a DSLR camera.
People think all professional cameras are called "SLRs".
A rangefinder is a higher quality camera than an SLR ever was and a full frame mirrorless probably has better quality than a DSLR, in both cases because it's easier to design lenses for them. A medium format camera can be better than all of those.
A medium format camera can also be a DSLR. An a6700 or an A7 is not a rangefinder, it's a mirrorless camera. You're mixing up characteristics.
DSLR means: it's digital, it uses one lens, and the visor image comes from the same lens that goes to the film, but reflected on a mirror to your eye (probably through a pentaprism, but that can vary), so you can see the same image that will be captured in the sensor.
A rangefinder is a camera where you look... through a rangefinder. It's a visor independent of the film/sensor, like a classic Leica. That means that the image you see is not exactly the same that will reach the sensor/film, as it will go through a different optical system. There are digital rangefinders like the M series Leicas.
Mirrorless means, it doesn't have a mirror to send the image to the visor. The typical mirrorless cameras nowadays get the visor image directly from the sensor, you don't look through a rangefinder. A rangefinder is mirrorless, but not every mirrorless is a rangefinder. Most digital mirrorless cameras aren't rangefinders.
A rangefinder (or mirrorless) camera is not inherently better than a DSLR. Mirrorless cameras can have simpler optical designs that achieve more quality easier, but there are better and worse cameras in both sides.
I know what a rangefinder and mirrorless are. I daresay you are correcting a lot of things I didn't actually say.
I went the extra step to clear those terms for anybody that could read it, just in case anybody is interested.
You said:
I say you're mixing stuff because:>A rangefinder is a higher quality camera than an SLR ever was
This does not mean anything at all. The comparison is total nonsense.
>and a full frame mirrorless probably has better quality than a DSLR
No. DSLR and Mirrorless camera differ how the viewfinder works. Generally Mirrorless cameras are newer, but ranking them for quality is totally nonsensical. This is independent of the size of the sensor.
>A medium format camera can be better than all of those.
You are comparing totally different things. A full frame Camera can be Mirrorless or a DSLR. There is no comparison to be made here. You are totally confused about technology and terminology.
A camera is a product with multiple components. Mirrorless camera designs can have smaller and higher quality lenses for the same price because they don't need to accommodate the SLR mirror behind the lens.
I don't think image quality is the end all be all of a camera, but is what amateurs think the purpose of an expensive camera is.
How is that relevant to anything you or I said?
Why are you talking about prices, when you were making absolute comparisons about what is better?
Because you can make anything good if it's infinitely expensive?
Respectfully, its not that simple. I dont think you know what you are talking about.
I think it's better to steelman rather than assert ignorance on the part of the person you're replying to.
It is true that people these days associate the DSLR form-factor with professional photography, despite the heavy use of rangefingers by those such as Robert Capa etc not that long ago. And it is also true that both rangefinders and mirrorless ILCs avoid the need for retrofocus designs which in theory should make for higher-quality lenses at the same weight, or similar quality and a lower weight.
As for "better" this is often a matter of preference and it's okay for people to have different preferences. For me personally, I wish there was more experimentation in ILC form factor, it seems most (with a few notable exceptions) ape the pentaprism hump even if they don't contain one.
I think it's easy to see what they mean, even if you don't agree with them. I think it puts too much emphasis on glass as there's so much more that goes into getting a shot. I do pick up my old film cameras every now and then for enjoyment, but if I have to get a shot, I'm always taking the newest thing I have. It's hard to beat multiple stops of stabilization in the lens and the body along with the black magic of modern sensors.
Alas, the people aren't ready for Ken Rockwell Theory.
Not having a mirror is not the most important characteristic of the hardware for this project.
Being able to control it through an API is. What happens after you trigger the shutter is out of scope. Speaking of shutter buttons, a bunch of new cameras don’t have shutters but the button is still called a shutter button.
While I mostly agree its a matter of jargon, the original author never calls their camera a DSLR.
Also yes while yes many cameras do not have moving shutters, they still operate with an electronic shutter which just like a moving one does have various limitations.
I'd argue though to many a photographer, calling any ILC or sufficiently costly camera a DSLR is akin to a post calling an android phone a linux phone. To the layperson the nuance between ubuntu's kernel or a pixel's doesnt matter to them, however to the intended audiences it sure does.
To be pedantic for the people still reading this, curious enough to go further without falling down a Wikipedia rabbit hole.
The reflex mirror in a (D)SLR directs the image up through the viewfinder prism to the eyepiece. This mirror flips upwards just before the shutter opens. This mechanic action has a decent bit of inertia and can cause blurring in some extreme cases.
Mirrorless refers to digital cameras where the sensor operates the digital viewfinder, so like an SLR “you get what you see”. For rangefinders and TLRs, your view is offset from the picture lens, so if you’re really trying to nail a composition and not “fix it in post” SLRs and mirrorless offer an advantage, which is part of why they became so predominant.
The repo originally said DSLR in the readme+description.
This is correct. I have ironed out my silly mistake just minutes after seeing comments of smarter people showing me the light.
No. When I see a6700 and DSLR used in the same sentence, I have to question whether that is a misunderstanding on the author's side, whether it's actually for Sony a6700 or some other camera, or if anything in the repo makes sense or if the author knows what they are doing. This erodes confidence if the author cannot even get the very basics right.
It's probably laziness AND misunderstanding on the author's side ;)
DLSR stands for Digital Single-Lens Reflex. An a6700 is indeed digital, has a single lens, and is undoubtedly a camera. All it’s missing is a reflex mechanism. So I’d say that in four out of five ways, it is indeed a DSLR camera.
No - it's "single-lens reflex", a single attribute without comma. That is, a mirror redirecting light from a single lens to different targets (viewfinder and film/sensor).
If "four out of five words" was good enough, then an analogue film camera is also a DSLR - it's only missing the "digital" part after all. Seahorse and racehorse is also just one word apart, so basically the same, right?
> an analogue film camera is also a DSLR
Funny you say that, as this is where the term originated.
Electronic (as opposed to mechanical) control of focus and controls were called ‘digital’ long before the advent of digital sensors.
The digital camera was invented in 1968, the first auto-focusing SLR is from 1978.
Auto-exposure came a few years before auto focus, but not by much as it still required not only light metering but also multiple mechanical couplings to the lens.
Such cameras (like the famous Canon A-1) were never refered to as "digital cameras", and SLR was used to distinguish from rangefinders primarily.
DSLR describes the basic operation mechanism of the camera. The A6700 does not have that mechanism, it has no optical viewfinder.
DSLR is an obsolete technology, just like your phone modern cameras can use their digital sensors to give a preview of the actual image on the sensor. Saying that some camera is a DSLR means something, namely that it uses an optical mechanism to project the light through the lense into a viewfinder. It is a technical term with a clear meaning, calling the A6700 a DSLR is wrong.
Sometimes four out of five doesn't cut it. Thats like claiming my car is an electric car because "they both have batteries and motors". Or like saying C is a functional programming language because its a programming language that "has functions".
The defining characteristic of SLR and DSLR cameras is the reflex mechanism, which is a giant mechanism inside the camera that sits in front of the film or sensor. The mechanism uses a mirror to allow the viewfinder to work. And the whole thing needs to physically flip out of the way when you press the shutter button to expose the film. But as a result, SLR / DSLR cameras are usually way bigger physically to make room for the mirror and the reflex mechanism.
Mirrorless cameras like the A6700 don't have this reflex mechanism, so they're not DSLR cameras. They're called mirrorless cameras. Same as the cameras in our phones.
You are correct.