[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)