Jman13 wrote:
Um, it makes it a huge improvement. All existing Sony bodies focus very slowly with Canon lenses on the Metabones. The A7R II in these videos is showing comparatively MUCH faster focus speeds. Does it answer the question of whether it can focus an 85mm or 300mm lens as fast as a Canon body? No, of course not, but it certainly shows that it uses PDAF and uses it quickly.
.....
+1.
I use the metabones adapter on my A7 with several Canon lenses but only for aperture control, the autofocus with the metabones adapter is a joke and not realistically usable (hunts for a ridiculous amount of time). The autofocus shown in those videos is truly usable autofocus for the vast majority of what I shoot. I also am waiting to see how the A7RII autofocus performance with longer lenses but what I have seen so far with shorter lenses is quite promising.
Regarding aperture; from the AI-S series and forwards, Nikon lens aperture is measured in exact amount of travel on the control arm.
Manual lenses (AI-S and forwards) did also need the maximum available aperture to be communicated to the camera body, that was done with the tab system on the aperture ring. In electronic control cameras (AF-S) this is done through the electrical contacts in stead.
I don't have the old datasheets here, but in general the system works with linear displacement. My numbers here are NOT THE REAL NUMBERS, it's just a way to explain!
number of stops from wide open = (arm travel in mm) / 1.5
So, if the arm is moved 5mm, then the camera wants the lens to stop down (5/1.5) = 3+1/3 stops
if the arm is moved 1mm, then the camera wants the lens to stop down (1/1.5) = 2/3 stops
This isn't that hard to link up from an electromechanical PoV, you need a position reference arm on the adapter that knows about the current aperture the body requests, that's all. But that control arm needs a bit of oompfh behind it to control the linkage system, so you need some serious power. Serious power in the context of small-mechanics in cameras that is... I'm just saying that you won't get away with a 1g 10mA microservo.
theSuede wrote:
Regarding aperture; from the AI-S series and forwards, Nikon lens aperture is measured in exact amount of travel on the control arm.
Manual lenses (AI-S and forwards) did also need the maximum available aperture to be communicated to the camera body, that was done with the tab system on the aperture ring. In electronic control cameras (AF-S) this is done through the electrical contacts in stead.
I don't have the old datasheets here, but in general the system works with linear displacement. My numbers here are NOT THE REAL NUMBERS, it's just a way to explain!
number of stops from wide open = (arm travel in mm) / 1.5
So, if the arm is moved 5mm, then the camera wants the lens to stop down (5/1.5) = 3+1/3 stops
if the arm is moved 1mm, then the camera wants the lens to stop down (1/1.5) = 2/3 stops
This isn't that hard to link up from an electromechanical PoV, you need a position reference arm on the adapter that knows about the current aperture the body requests, that's all. But that control arm needs a bit of oompfh behind it to control the linkage system, so you need some serious power. Serious power in the context of small-mechanics in cameras that is... I'm just saying that you won't get away with a 1g 10mA microservo....Show more →
Thank you, very good to know!
BTW, did anybody else see that Sony has officially stated they're considering / already working on RAW compression options for firmware updates? Take that, haters!
Yes, meant to answer those points earlier, but ran out of battery on the train...
There is no compression on the sensor. Exmor API's normally limit the programming steps to:
-bin type (depends on sensor model, not available on all)
-crop area
-bit depth
-black zero level
Some of the later sensors have a few other options in programmable modes too, but nothing regarding compression.
That's to bad, since gamma-compression in ADC's (non-linear comparator ramps) can increase the read-speeds by up to 30-40% without sacrificing read accuracy or tone resolution. But it makes the later stages of processing harder (to do correctly, from a color-interpretation PoV).
The rest is linear communication protocols that serialize the output data feeds.
And it's pure BS that the Bionz processors are 12-bit precision limited - they've been 16-bit precision since the A700 back in 2007-8 (?year?). It's very hard to make 16-bit and 32-bit processors handle lower-precision data flows, you'd have to incorporate memory-compression stages to work your way around the 32-bit wide memory bus. For a low-energy portable (battery-based) implementation, that's not really an option unless you have the entire ARM division behind you and several million processors per quarter in turnaround. Modern phone and tablet graphics processors do this (memory compression to lower the bandwidth demands on GDDR).
The Bionz-X is unfortunately also 16-bit math precision, I'd have hoped for more since the built in HDR-functions are really good.
Sony do seems to stumble on their own shoelaces on quite a few steps later in the processing chain though, the compression type used in ARW and ARW2-type compression is one of them. Value round-off errors are also quite sloppily handled in some of the implementations.
theSuede wrote:
Yes, meant to answer those points earlier, but ran out of battery on the train...
There is no compression on the sensor. Exmor API's normally limit the programming steps to:
-bin type (depends on sensor model, not available on all)
-crop area
-bit depth
-black zero level
Some of the later sensors have a few other options in programmable modes too, but nothing regarding compression.
That's to bad, since gamma-compression in ADC's (non-linear comparator ramps) can increase the read-speeds by up to 30-40% without sacrificing read accuracy or tone resolution. But it makes the later stages of processing harder (to do correctly, from a color-interpretation PoV).
The rest is linear communication protocols that serialize the output data feeds.
And it's pure BS that the Bionz processors are 12-bit precision limited - they've been 16-bit precision since the A700 back in 2007-8 (?year?). It's very hard to make 16-bit and 32-bit processors handle lower-precision data flows, you'd have to incorporate memory-compression stages to work your way around the 32-bit wide memory bus. For a low-energy portable (battery-based) implementation, that's not really an option unless you have the entire ARM division behind you and several million processors per quarter in turnaround. Modern phone and tablet graphics processors do this (memory compression to lower the bandwidth demands on GDDR).
The Bionz-X is unfortunately also 16-bit math precision, I'd have hoped for more since the built in HDR-functions are really good.
Sony do seems to stumble on their own shoelaces on quite a few steps later in the processing chain though, the compression type used in ARW and ARW2-type compression is one of them. Value round-off errors are also quite sloppily handled in some of the implementations....Show more →
IR has an interview with the head of Sony's mirrorless group.
Great and interesting interview... he again confirmed that uncompressed RAW is in the works (but no timeline) and that the issue could be addresses via firmware.
How they got to the magical 42MP was also interesting.
Here is a snip but you should read the entire article:
"This next question is more of a request maybe, but we've had a lot of questions asking about raw format. And...
KM: Ah, raw. <laughs> 14-bit.
DE: Yeah, well 14-bit is OK, but many people are asking "could we please have uncompressed RAWs?"
KM: Sony RAW is compressed, not uncompressed. But if we're getting a lot of requests for it, we should make such a kind of no-compression raw. Of course we recognize that. But I cannot give you a guarantee when we're going to fix or not fix.
DE: Right. When you're going to address that, yeah.
KM: Sure, sure. And so we recognize the customer's requirement, and actually we are working on it.
DE: So it's something that you're aware of. I'm sure that the image processing pipeline is optimized for the way that it is now, but it seems to me that, while it might involve some trading off some performance, that it could just be a firmware change. Could it? Would you be able to provide uncompressed raw as a firmware update, or would it require new hardware?
KM: Right, yes. So... not hardware.
DE: It is firmware. OK, good! I think people would be willing to accept a slower transfer time or lower frame rate in an uncompressed mode. Some people really, really want that."
johntruong wrote:
IR has an interview with the head of Sony's mirrorless group.
Great and interesting interview... he again confirmed that uncompressed RAW is in the works (but no timeline) and that the issue could be addresses via firmware.
How they got to the magical 42MP was also interesting.
Here is a snip but you should read the entire article:
"This next question is more of a request maybe, but we've had a lot of questions asking about raw format. And...
KM: Ah, raw. <laughs> 14-bit.
DE: Yeah, well 14-bit is OK, but many people are asking "could we please have uncompressed RAWs?"
KM: Sony RAW is compressed, not uncompressed. But if we're getting a lot of requests for it, we should make such a kind of no-compression raw. Of course we recognize that. But I cannot give you a guarantee when we're going to fix or not fix.
DE: Right. When you're going to address that, yeah.
KM: Sure, sure. And so we recognize the customer's requirement, and actually we are working on it.
DE: So it's something that you're aware of. I'm sure that the image processing pipeline is optimized for the way that it is now, but it seems to me that, while it might involve some trading off some performance, that it could just be a firmware change. Could it? Would you be able to provide uncompressed raw as a firmware update, or would it require new hardware?
KM: Right, yes. So... not hardware.
DE: It is firmware. OK, good! I think people would be willing to accept a slower transfer time or lower frame rate in an uncompressed mode. Some people really, really want that."...Show more →
It's a bit concerning that Sony themselves are using this "compressed" vs "uncompressed" terminology when speaking of an issue which is about lossy compression versus lossless compression. The important bit - lossy vs lossless- seems to be missing (which makes me wonder if the Sony folks doing the talking know what they are even talking about). I don't think anyone really wants a fully non-compressed raw (as long as we get lossless compressed raw).
It's a bit concerning that Sony themselves are using this "compressed" vs "uncompressed" terminology when speaking of an issue which is about lossy compression versus lossless compression. The important bit - lossy vs lossless- seems to be missing. I don't think anyone really wants a fully non compressed raw (as long as we get lossless compressed raw).
It's less engineering effort to provide uncompressed RAW than to support two different versions of compression.
Frankly, given the almost-nonexistent problem with the current RAW compression I think an option of uncompressed + the current RAW compression is fair enough.
People can use uncompressed when shooting star trails, and the existing ARW the rest of the time...
lightskyland wrote:
It's less engineering effort to provide uncompressed RAW than to support two different versions of compression.
Frankly, given the almost-nonexistent problem with the current RAW compression I think an option of uncompressed + the current RAW compression is fair enough.
People can use uncompressed when shooting star trails, and the existing ARW the rest of the time...
...but Sony already have in-house a version of compressed, lossless raw which they offered simultaneously with craw (lossy raw) many years ago. I think offering a fully uncompressed raw is a bit crazy in this day and age (2:1 lossless compression should be no big deal).
Tariq Gibran wrote:
...but Sony already have in-house a version of compressed, lossless raw which they offered simultaneously with craw (lossy raw) many years ago. I think offering a fully uncompressed raw is a bit crazy in this day and age (2:1 lossless compression should be no big deal).
The 700 & 900 had uncompressed raw and craw which was the 11/7 lossy compression. They didn't have compressed lossless raw. My A900 files are 35-40 mega bytes in size with full raw. By the way speed difference between the two raws is negligible.
mogul wrote:
The 700 & 900 had uncompressed raw and craw which was the 11/7 lossy compression. They didn't have compressed lossless raw. My A900 files are 35-40 mega bytes in size with full raw. By the way speed difference between the two raws is negligible.
You are wrong about that as they certainly did with the A900 and I used it!
A typical lossless compressed raw file from the A900 is around 36MB's and opens to about twice that size. It's roughly 2:1 compression. Ironically, this size - 36MB's - is very close to the lossy compressed raw from my 36MP A7r.
Tariq Gibran wrote:
You are wrong about that as they certainly did with the A900 and I used it!
A typical lossless compressed raw file from the A900 is around 36MB's and opens to about twice that size. It's roughly 2:1 compression. Ironically, this size - 36MB's - is very close to the lossy compressed raw from my 36MP A7r.
Hmmm A900 was 24MP and had 12bits per sample i.e. 1.5 bytes per sample and 24 * 1.5 = 36. So if A900 raw files were 36MP then it indicates there was no compression. It does indicate that the data was packed i.e. it didn't waste 16-bits to store 12-bits but no real compression
Tariq Gibran wrote:
You are wrong about that as they certainly did with the A900 and I used it!
A typical lossless compressed raw file from the A900 is around 36MB's and opens to about twice that size. It's roughly 2:1 compression. Ironically, this size - 36MB's - is very close to the lossy compressed raw from my 36MP A7r.
You certainly could be right; the way I understood raw was uncompressed was about 1/3 more than sensor size but that is a problem that I assumed, probably incorrectly.
curious80 wrote:
Hmmm A900 was 24MP and had 12bits per sample i.e. 1.5 bytes per sample and 24 * 1.5 = 36. So if A900 raw files were 36MP then it indicates there was no compression. It does indicate that the data was packed i.e. it didn't waste 16-bits to store 12-bits but no real compression
The opened a900 raw is always around 2x (69.8MB's to be exact) when opened at 8bit and saved out as 8bit tiff. Maybe there is a different way to talk about compression but this is how I've always understood it (saved file size from camera versus opened file size). Long ago (early digital days) I believe raws (which were typically based on a tiff format, maybe they still are?) were around the same size as the opened file (thus they were not compressed).
Now I'm curious to here from the expert about this (theSuede or...).
Tariq Gibran wrote:
The opened a900 raw is always around 2x (69.8MB's to be exact) when opened at 8bit and saved out as 8bit tiff. Maybe there is a different way to talk about compression but this is how I've always understood it. Long ago (early digital days) I believe raws (which were typically based on a tiff format, maybe they still are?) were around the same size as the opened file (thus they were not compressed).
The raw files have no color data so they have only one sample per pixel. When you open it you don't see the raw data, you see the demosaiced image in which the missing RGB samples have been filled in through interpolation. So that should increase the overall data by 3 times. However then you also go from 12-bit to 8 bit which reduces the size by 1.5x and you get to an overall 2x increase over RAW data.
Now I'm curious to here from the expert about this (theSuede or...).
While I am certainly not an expert like theSuede, I think this does fall within the realm of my limited knowledge
curious80 wrote:
The raw files have no color data so they have only one sample per pixel. When you open it you don't see the raw data, you see the demosaiced image in which the missing RGB samples have been filled in through interpolation. So that should increase the overall data by 3 times. However then you also go from 12-bit to 8 bit which reduces the size by 1.5x and you get to an overall 2x increase over RAW data.
While I am certainly not an expert like theSuede, I think does fall within the realm of my limited knowledge
Well, if you are correct, it's interesting as this is not the typical way compression is talked about generally (not by engineers but such as in Photo schools). The use of the term compression in this setting refers to saved file size by camera vs opened file size, which is where the 2:1 compression comes in for the raw format that Sony once used.
If by "uncomprssed" Sony is talking about offering a raw that is half the size of the opened 8bit file, then I would have no issue with that as it would be the same as they once offered (such as in the A900).
Tariq Gibran wrote:
Well, if you are correct, it's interesting as this is not the typical way compression is talked about generally (not by engineers but such as in Photo schools). The use of the term compression in this setting refers to saved file size by camera vs opened file size, which is where the 2:1 compression comes in for the raw format that Sony once used.
If by "uncomprssed" Sony is talking about offering a raw that is half the size of the opened 8bit file, then I would have no issue with that as it would be the same as they once offered (such as in the A900).
Well if you want to call it compression then in this case 'compression' is being performed by the bayer sensor by throwing away 2/3rd of the data at every pixel The RAW file itself is recording all the 36MByte of data from the sensor without any compression. When people talk of lossless compression in RAW files they are talking about techniques like ones used in ZIP files, using which you can store the 36MByte of RAW sensor data in less space but don't throw away any information while doing so.
curious80 wrote:
Well if you want to call it compression then in this case 'compression' is being performed by the bayer sensor by throwing away 2/3rd of the data at every pixel The RAW file itself is recording all the 36MByte of data from the sensor without any compression. When people talk of lossless compression in RAW files they are talking about techniques like ones used in ZIP files, using which you can store the 36MByte of RAW sensor data in less space but don't throw away any information while doing so.
Is there any downside to compressing lossless? Why wouldn't Sony use it?
I'm just saying that you won't get away with a 1g 10mA microservo.