31–40 of 75 posts
How badly will its lossy-ness change critical things? In 2013, there were Xerox copiers with aggressive compression that changed numbers, https://www.theregister.com/2013/08/06/xerox_copier_flaw_mea...
How badly will its lossy-ness change critical things? In 2013, there were Xerox copiers with aggressive compression that changed numbers, https://www.theregister.com/2013/08/06/xerox_copier_flaw_mea...
Earlier quoted context omitted.
Yes, I do mean broad- rather than niche adoption. I myself used J2K to archive film scans. One problem is that without broad adoption, support even in niche cases is precarious; the ecosystem is smaller. That makes the codec not safe for archiving, only for distribution. The strongest use case I see for this is streaming video, where the demand for compression is highest.
For archiving, I'd recommend having a wasm decompressor along with some reference output. Could also ship an image viewer as an html file with all the code embedded.
How badly will its lossy-ness change critical things? In 2013, there were Xerox copiers with aggressive compression that changed numbers, https://www.theregister.com/2013/08/06/xerox_copier_flaw_mea...
If I zoom all the way with my iPhone, the camera-assisting intelligence will mess up numbers too
Anyone know of open models useful (and good quality) for going the other way? I.e., Input is a 800x600 jpg and output is 4k version.
Magnific.ai ( https://magnific.ai ) is a paid tool that works well, but it is expensive. However, this weekend someone released an open-source version which has a similar output. ( https://replicate.com/philipp1337x/clarity-upscaler ) I'd recommend trying it. It takes a few tries to get the correct input parameters, and I've noticed anything approaching 4× scale tends to add unwanted hallucinations. For example, I ha…
Earlier quoted context omitted.
Did JPEG2000 really flounder? If your concept of it being a consumer facing product as a direct replacement for JPEG, then I could see being unsuccessful in that respect. However, JPEG2000 has found its place in the professional side of things.
Yes, I do mean broad- rather than niche adoption. I myself used J2K to archive film scans. One problem is that without broad adoption, support even in niche cases is precarious; the ecosystem is smaller. That makes the codec not safe for archiving, only for distribution. The strongest use case I see for this is streaming video, where the demand for compression is highest.
Could you explain what you mean by "not safe for archiving"? The standard is published and there are multiple implementations, some of which are open-source. There is no danger of it being a proprietary format with no publicly available specification.
Earlier quoted context omitted.
Yes, I do mean broad- rather than niche adoption. I myself used J2K to archive film scans. One problem is that without broad adoption, support even in niche cases is precarious; the ecosystem is smaller. That makes the codec not safe for archiving, only for distribution. The strongest use case I see for this is streaming video, where the demand for compression is highest.
That makes the codec not safe for archiving, only for distribution. Could you explain what you mean by "not safe for archiving"? The standard is published and there are multiple implementations, some of which are open-source. There is no danger of it being a proprietary format with no publicly available specification.
As a counter, J2K has been well established by the professional market even if your mom doesn't know anything about what it is. It has been standardized by the ISO, so it's not something that will be forgotten about. It's a good tool for the right job. It's also true that not all jobs will be the right ones for that tool
Earlier quoted context omitted.
If I zoom all the way with my iPhone, the camera-assisting intelligence will mess up numbers too
The mentioned Xerox copier incident was not an OCR failure, but the copier actively changed the numbers in the original image due to its image compression algorithm.
Learn More: https://www.dkriesel.com/start?do=search&id=en%3Aperson&q=Xe...
Brief: Xerox machines used template matching to recycle the scanned images of individual digits that recur in the document. In 2013, Kriesel discovered this procedure was faulty.
Rationale: This method can create smaller PDFs, advantageous for customers that scan and archive numerical documents.
Prior art: https://link.springer.com/chapter/10.1007/3-540-19036-8_22
Tech Problem: Xerox's template matching procedure was not reliable, sometimes "papering over" a digit with the wrong digit!
PR Problem: Xerox press releases initially claimed this issue did not happen in the factory default mode. Kriesel demonstrated this was not true, by replicating the issue in all of the factory default compression modes including the "normal" mode. He gave a 2015 FrOSCon talk, "Lies, damned lies and scans".
Interesting work!
Earlier quoted context omitted.
For archiving, I'd recommend having a wasm decompressor along with some reference output. Could also ship an image viewer as an html file with all the code embedded.
Why the need for all things to be browser based? Why introduce the performance hit for something that brings no compelling justification? What problem is this solution solving? Why can't things just be native workflows and not be shoveled into a browser?
Truly standard ANSI C along with a number of other implementation strategies (LLVM IR seems unlikely to be going anywhere) seem just as durable as WASM if not more, but there are applications where you might not want to need a C toolchain and WASM can be a fit there.
One example is IIUC some of the blockchain folks use WASM to do simultaneous rollout of iterations to consensus logic in distributed systems: everyone has to upgrade at the same time to stay part of the network.