At least two different Sony spokespeople, some quite technical, have said that it can be fixed in firmware. If that's so, it's very unlikely that it involves reprogramming specialzed chips, so it's more likely to be done by the generalized image processing chip.
DavidBM wrote:
At least two different Sony spokespeople, some quite technical, have said that it can be fixed in firmware. If that's so, it's very unlikely that it involves reprogramming specialzed chips, so it's more likely to be done by the generalized image processing chip.
No doubt "a" fix could be implemented in firmware. But with all things related to algorithms, there are tradeoffs and i'm just wondering at this point if the solution they're contemplating is "work around" because the current pipeline is set in the hardware, then any such firmware fix may be slow and/or battery intensive. Which is why it would be nice if the chip that implements the current lossy compression could be re-programmed to take advantage of whatever hardware currently exists rather than have to implement the lossless compression in a general processor. My guess is that the reason it has yet to be implemented, especially in the a7r2, which they seem to have addressed almost every other concern (to their credit) is that the current pipeline limits their flexibility to implement this efficiently. Just a guess b/c i have zero knowledge of their current chipset.
ecarlino wrote:
No doubt "a" fix could be implemented in firmware. But with all things related to algorithms, there are tradeoffs and i'm just wondering at this point if the solution they're contemplating is "work around" because the current pipeline is set in the hardware, then any such firmware fix may be slow and/or battery intensive. Which is why it would be nice if the chip that implements the current lossy compression could be re-programmed to take advantage of whatever hardware currently exists rather than have to implement the lossless compression in a general processor. My guess is that the reason it has yet to be implemented, especially in the a7r2, which they seem to have addressed almost every other concern (to their credit) is that the current pipeline limits their flexibility to implement this efficiently. Just a guess b/c i have zero knowledge of their current chipset....Show more →
I suspect Sony have been telling folks what they want to hear with regard to lossy raw compression. Hopefully I'm wrong but they may be in the process of "walking this back" where we don't actually see lossless raw with the A7rII (otherwise, I think it would already be there).
This latest statement from Sony via Dpreview seems a bit iffy to me and part of the walkback process (just as all the previous "woulds and coulds" have). My bet is the way they "deal with it" is with a new Pro model - with new processors/ chips - eventually.
"One of our main criticisms of the a7-series has been raw compression. Is the raw processing of the a7R II the same as previous cameras?
KM: Right now it is the same, yes. We’re still working on it. In the future we may change the software but that’s not completed yet. We have consumers who require 14-bit etc., and we’re considering [how to deal with it]."
Tariq Gibran wrote:
I suspect Sony have been telling folks what they want to hear with regard to lossy raw compression. Hopefully I'm wrong but they may be in the process of "walking this back" where we don't actually see lossless raw with the A7rII (otherwise, I think it would already be there).
several have speculated that the Sony guys keep referring to "uncompressed raw" as being a mistake or mis-translation - but i'd guess that a firmware add-on would be more likely to just dump uncompressed raw to the card rather than implementing any lossless compression algorithm. so maybe when they've been saying 'uncompressed raw' that's what they actually meant. perhaps the b.s. part is that they keep saying that that is what their customers have been requesting (which i can't imagine anyone who knows anything wanting uncompressed raw vs. lossless compressed).
i'm thinking that the entire pipeline is probably setup to deal with data in a certain existing format and it may take a new version of the bionzx or other chips to offer lossless compressed on future models.
ecarlino wrote:
several have speculated that the Sony guys keep referring to "uncompressed raw" as being a mistake or mis-translation - but i'd guess that a firmware add-on would be more likely to just dump uncompressed raw to the card rather than implementing any lossless compression algorithm. so maybe when they've been saying 'uncompressed raw' that's what they actually meant. perhaps the b.s. part is that they keep saying that that is what their customers have been requesting (which i can't imagine anyone who knows anything wanting uncompressed raw vs. lossless compressed).
i'm thinking that the entire pipeline is probably setup to deal with data in a certain existing format and it may take a new version of the bionzx or other chips to offer lossless compressed on future models....Show more →
That makes sense with regard to the possible necessity of uncompressed raw with the existing hardware.
I think you guys are on to something here. I haven't seen anyone request uncompressed RAW, yet it is what Sony are saying, and thus what they say they are considering. Maybe because they could do uncompressed RAW more easily than lossless compressed... But those files are going to be large...
In the interviews I've read it's the interviewer who asks about uncompressed raw and the Sony person responds in like. I'd prefer to hear the interviewer ask specifically about lossless compression or uncompressed raw and see what they say.
ecarlino wrote:
i'm thinking that the entire pipeline is probably setup to deal with data in a certain existing format and it may take a new version of the bionzx or other chips to offer lossless compressed on future models.
Yeah, but there's no excuse for the A7 II models not having that new version, people have been telling them they want this since the day the A7 was announced. There's no reason it should take them three generations (more if you count the NEX) to figure out something CaNikon have been doing for 15 years.
Sony's been very "one step forward, two steps back" with their innovation.
Lee Saxon wrote:
Yeah, but there's no excuse for the A7 II models not having that new version, people have been telling them they want this since the day the A7 was announced. There's no reason it should take them three generations (more if you count the NEX) to figure out something CaNikon have been doing for 15 years.
Sony's been very "one step forward, two steps back" with their innovation.
Lenses, sensors, and cameras are 3 distinct groups. That's why innovation sometimes seems disjointed.
I'm not sure who is responsible for the BIONZX (a 4th group?), but my guess is that it's inside of that chip where the problem lies and the current generation inherited it's architecture (and limitations) from its predecessor.
kwalsh wrote:
Um, you do realize that ITU T.81 is in fact the specification for lossless JPEG compression. Which is what was being referred to. You basically proved yourself wrong with your own post and reference to the spec.
You are right, I should have written "it does not use the DCT (Discrete Cosine Transform)".
What I took issue with is the "take the difference between the compressed and original and store that using entropy encoding" explanation, which is incorrect. In T.81 it is the difference between neighboring pixels which is encoded using Huffman coding. Canon also have a permutation of the pixels, which I think reflects the readout from the sensorn. (Sorry for the late reply, I managed to overlook you reply),
ClausC wrote:
You are right, I should have written "it does not use the DCT (Discrete Cosine Transform)".
What I took issue with is the "take the difference between the compressed and original and store that using entropy encoding" explanation, which is incorrect. In T.81 it is the difference between neighboring pixels which is encoded using Huffman coding. Canon also have a permutation of the pixels, which I think reflects the readout from the sensorn. (Sorry for the late reply, I managed to overlook you reply),
Ah, I see the misunderstanding - JPEG vs DCT. So many acronyms, so much fast typing
Understand what you meant now, and yes your objection is sensible. I hadn't noticed the mention of differential encoding in the post you were replying to. It has a been years since I looked at CR2 so I'm sure your recollection of its encoding method from T.81 is a lot better than mine!
As an aside there is in fact a lossless mode in T.81 which does in fact work as "take the difference between the compressed and original and store that using entropy encoding". That is the hierarchical mode which allows for at any point in the tree to switch to lossless encoding. Thus you can create lossless JPEG using T.81 hierarchical mode which has a first frame that is a lossy DCT based compressed image and a second frame which is the difference between the original image and the first frame that is entropy encoded. I'm guessing that is what the poster you responded to was thinking of. I haven't the foggiest as to how often at all that implementation is used by anyone nor whether it is used in any RAW format either. But it is a mode described in T.81.
