[HN Gopher] Canon CR3 Fileformat ___________________________________________________________________ Canon CR3 Fileformat Author : tosh Score : 43 points Date : 2021-01-09 19:21 UTC (3 hours ago) (HTM) web link (github.com) (TXT) w3m dump (github.com) | auxym wrote: | 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 | smnrchrds wrote: | 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. | mhh__ wrote: | 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 | meibo wrote: | IP is very highly valued and (usually) well-respected over | there, so I can imagine that this is part of the reason. | ekianjo wrote: | > 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. | gotem wrote: | Wonder if one day we will be able to store files using 0 storage. | Complete compression. | jsheard wrote: | The LenPEG algorithm can compress images down to 0 bytes in the | best case | | https://www.dangermouse.net/esoteric/lenpeg.html | gotem wrote: | I thought you were being sereis but it only works for 1 image | at 0z | BlueTemplar wrote: | I see that the best case is actually a negative, unbounded | number of bytes? | buildbot wrote: | 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 | herf wrote: | Recent notes are all about HEIF (~= iOS HEIC). It seems alarming | to me that so many devices (Canon and iPhone at least) are | putting out patent-encumbered HEIF/HEIC files _while_ the | available decoders are so incredibly slow. | | 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 | zadokshi wrote: | > "... 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) | hamburglar wrote: | Next you're going to tell us webservers don't send email, or | perform searches, or move money around in bank accounts. | mehrdadn wrote: | > Webservers don't encode/decode images | | Thumbnail generation? | threatripper wrote: | Except if they need to process them e.g. to create a | thumbnail or a preview. ___________________________________________________________________ (page generated 2021-01-09 23:00 UTC)