How much disk space do I use in a year of hybrid camera use?

[dazzerfong]

Where is the mathematical proof that its identical to the non-compressed file after decompression? Like I said no one has provided that...

I literally gave you proof, and you didn't even recognise it as such. You don't have to take my word that it's an ljpeg92 encoding, I linked it on Rawtherapee's repo!

You literally cannot do that test you proposed because the sensor will always have random noise, thus two pictures (even if uncompressed) will literally never have the same raw acquisition.

Proof is there, again, not my problem or Sony's you don't understand it. Here it is again: https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/libraw/src/decoders/sonycc.cpp

Or if you want it straight from LibRaw (which is where RT poached it from):

https://github.com/LibRaw/LibRaw/blob/master/src/decoders/sonycc.cpp

If you want more proof, Darktable also supports it through their rawspeed library: this one's a little bit easier to explain. See for their ARW decoder, look at line 178 and follow from there: it calls the DecodeLJpeg function which then, after scraping all the info necessary, passes it to LJpegDecoder in line 381. There, in line 101 it calls AbstractLJpegDecoder which is what actually decodes it.

Again thanks for this, if nothing else it confirms we are seeing the same thing to this point. I prefer to decode the files and work with them in cli to so I can see all the backend work that's being performed and or do additionally logging if possible. Libraw should be all I need ...

Curious to see how you're going to confirm the results now..........

To be honest I am not sure it is worth sharing because, something regarding my methodology will be attacked or criticized. The info you have shared about the predictive encryption helped a lot with how I was looking at this.
A lot of this is confusion around terms and definitions, and I don't want to argue that. I would just rather look at the data, and see what Sony is doing to the files...

Not that it matters I just want to know...

I'm more interested to see how logging would be any different to just reading the code, but hey every developer has their own way of seeing how things work.....

 

[Impulses]

Where is the mathematical proof that its identical to the non-compressed file after decompression? Like I said no one has provided that...

I literally gave you proof, and you didn't even recognise it as such. You don't have to take my word that it's an ljpeg92 encoding, I linked it on Rawtherapee's repo!

You literally cannot do that test you proposed because the sensor will always have random noise, thus two pictures (even if uncompressed) will literally never have the same raw acquisition.

Proof is there, again, not my problem or Sony's you don't understand it. Here it is again: https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/libraw/src/decoders/sonycc.cpp

Or if you want it straight from LibRaw (which is where RT poached it from):

https://github.com/LibRaw/LibRaw/blob/master/src/decoders/sonycc.cpp

If you want more proof, Darktable also supports it through their rawspeed library: this one's a little bit easier to explain. See for their ARW decoder, look at line 178 and follow from there: it calls the DecodeLJpeg function which then, after scraping all the info necessary, passes it to LJpegDecoder in line 381. There, in line 101 it calls AbstractLJpegDecoder which is what actually decodes it.

Again thanks for this, if nothing else it confirms we are seeing the same thing to this point. I prefer to decode the files and work with them in cli to so I can see all the backend work that's being performed and or do additionally logging if possible. Libraw should be all I need ...

Curious to see how you're going to confirm the results now..........

To be honest I am not sure it is worth sharing because, something regarding my methodology will be attacked or criticized.

Isn't that part of the scientific process? I'd be curious to see what you come up with, and not because I'd wanna poke holes in it. I did so for the aforementioned YT clip because I thought the issues were plainly obvious and it sent the guy on a wild goose chase, I hope he was using MF for those tests but something tell me he wasn't, or messed up elsewhere and didn't bother to figure out why... Isn't that important?

The info you have shared about the predictive encryption helped a lot with how I was looking at this.
A lot of this is confusion around terms and definitions, and I don't want to argue that. I would just rather look at the data, and see what Sony is doing to the files...

Not that it matters I just want to know...

Knowing is half the battle, knowledge is power, etc.

 

[Gloomy1]

Sorry! You have misread my comment, I could have phrased it better. The amateur referred to is myself. I was merely telling you how much data I had produced in 2024. I, unlike some, do not get aggressive in my comments, but you are not to know that. Happy New Year from a snowy North of Scotland. Ken

 

[jhunna]

Sorry! You have misread my comment, I could have phrased it better. The amateur referred to is myself. I was merely telling you how much data I had produced in 2024. I, unlike some, do not get aggressive in my comments, but you are not to know that. Happy New Year from a snowy North of Scotland. Ken

Thanks for that Ken. Happy New Year to you too