The A6700 is not, in any way, a DSLR camera.
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.
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.
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.
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
- 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 thatThis 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.
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.
Why are you talking about prices, when you were making absolute comparisons about what is better?
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.
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.
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 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.
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?
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.
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 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.
Suggestions: DShelLR, dshr, dslr-sh, camshell
- 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.
They're firmly stuck in the early 1990s in terms of system software.
Curiously the Z8 (which is basically a Z9) and the Zf (which is basically a Z6 iii) don’t support STA.
The problem is with the software. It disconnects and sends data incredibly slowly, orders of magnitude slower than what the hardware is capable of.
> ... and (the most affordable API) supporting cameras
when it was (probably?) meant as:
> ... and the most affordable (API supporting cameras)
https://sourceforge.net/p/pentaxks2wifiremote/wiki/K-S2%20We...
The Magnuson-Moss Warranty Act would like a word.
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
Is there anywhere a group focusing on understanding and re-implementing custom PTP protocols?
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?
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.
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).
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.
On some cameras, including the older firmwares for the current cameras, https://github.com/ma1co/Sony-PMCA-RE gives you a root shell.
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.
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.
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.
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.
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
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!
- 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.
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/...
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 :(
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.
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.
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).
Thanks for the heads up about this!
beligum•4mo ago
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!
SAI_Peregrinus•4mo ago
simondotau•4mo ago
a96•4mo ago
https://en.wikipedia.org/wiki/Contemporary_art
delta_p_delta_x•4mo ago
Lammy•4mo ago
anArbitraryOne•4mo ago
JdeBP•4mo ago
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.
beligum•4mo ago
pjmlp•4mo ago
Instead of
Use the filesystem API, -- https://en.cppreference.com/w/cpp/filesystem.htmlbeligum•4mo ago