Canon CR3 Fileformat(github.com)
github.com
Canon CR3 Fileformat
https://github.com/lclevy/canon_cr3
24 comments
This is temporary, for sure. The phones are also recording video in patent-encumbered MPEG-4, recording audio using patent-encumbered AAC. The ability to watch MPEG-4 and listen to AAC files was kinda terrible for a long time, but these days is fairly good. It just takes time.
What's alarming is the continued existence (and respect) of software patents.
Until software patents are abolished, developers and consumers will continue to be ripped off.
Until software patents are abolished, developers and consumers will continue to be ripped off.
> "... makes these formats unworkable for a whole lot of things, like most webservers"
Webservers don't encode/decode images, they simply need to send them. (But yes, overall, I agree)
Webservers don't encode/decode images, they simply need to send them. (But yes, overall, I agree)
Except if they need to process them e.g. to create a thumbnail or a preview.
Which you do once or twice per upload? That shouldn't be a massive CPU burden either.
That can be done by a daemon.
[deleted]
Next you're going to tell us webservers don't send email, or perform searches, or move money around in bank accounts.
(To be precise, HEIC is HEIF with the primary image guaranteed to be compressed with HEVC.)
Uggh. At the moment, many open source photography software projects are lacking support for CR3 due to an ambiguous patent situation. It seems that CR3 may include technologies covered by some patents, and Canon has refused to comment on whether or not they intend to pursue legal action against open source reader implementations. The response of the developers has been, undertstandably, to forego implementation in order to avoid getting sued.
https://github.com/darktable-org/darktable/issues/2170
https://github.com/darktable-org/darktable/issues/2170
Half the battle isn't even about implementing patented technology, it's just understanding the file layout and the meaning of various flags and headers. There's no legal risk to Canon in releasing that basic documentation but they still refuse to do so.
I've used Canon kit for over 30 years but I'm not going to upgrade to CR3 cameras if they maintain this obtuse attitude.
I've used Canon kit for over 30 years but I'm not going to upgrade to CR3 cameras if they maintain this obtuse attitude.
What's the incentive for Canon not to comment on this? Are they charging license fees for use of CR3? Considering the fact that their product is hardware, not software, I do not understand what they stand to gain by keeping the patent situation ambiguous.
Is it a cultural thing due to them being Japanese? The way nintendo treat their customers seems to be usually waved off as a Japanese thing
I'm not familiar with the way Nintendo treats their customers. Can anyone fill me in?
IP is very highly valued and (usually) well-respected over there, so I can imagine that this is part of the reason.
> Is it a cultural thing due to them being Japanese?
Definitely a factor. By default, Japanese companies tend to avoid or be reluctant to disclosing/sharing anything.
Definitely a factor. By default, Japanese companies tend to avoid or be reluctant to disclosing/sharing anything.
Small world! One of the contributors to this project created the only open source firmware for a digital back, as far as I know:
https://github.com/Alexey-Danilchenko
Wonder if one day we will be able to store files using 0 storage. Complete compression.
The LenPEG algorithm can compress images down to 0 bytes in the best case
https://www.dangermouse.net/esoteric/lenpeg.html
https://www.dangermouse.net/esoteric/lenpeg.html
I see that the best case is actually a negative, unbounded number of bytes?
I thought you were being sereis but it only works for 1 image at 0z
Part of the answer: https://en.wikipedia.org/wiki/Shannon%27s_source_coding_theo...
You could also think about lossy compression that is indistinguishable from lossless for the human eye, then you get another (lower) lower bound.
You could also think about lossy compression that is indistinguishable from lossless for the human eye, then you get another (lower) lower bound.
Last I looked, libHEIF is >50x slower than the built-in iOS decoders, which makes the format hundreds of times slower to decode than JPEG. With JPEG, the differences between free decoders and the "best" ones has been 2-3x in speed, but 50x slower is a huge cost that makes these formats unworkable for a whole lot of things, like most webservers.
Does anyone know if things are getting better here?
As an example, here are some 2019 benchmarks of Apple's HEIC decoder vs. libHEIF:
https://github.com/joedrago/avif/issues/11