The big story here is this introduces a new image file format without requiring you to upgrade a browser or download a plugin. Those aren't PNGs of representative images you're looking at - that's BPG decoding happening in your browser.
So we don't like HVEC due to patent worries? Fine, we can swap in another format and use the same technique.
We don't have an I-frame format for Daala that's finalized yet? Fine, we can use work-in-progress. The format does not need to be finalized. If you update it, you rebuild your images and bundle a new JavaScript decoder.
The ability to ship media along with a sandboxed, runnable decoder is awesome, and I'm surprised it hasn't caught on until now. I remember Google a while back implemented their own "video" codec in JavaScript using JPEGs and primitive inter-frame processing, exactly because there wasn't a universal video codec format they could use.
Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? If it downloads them itself, then any parallel fetching by browsers will stop working. And if they are decoded by javascript, they will take (very slightly) longer, and both the encoded and decoded images need to be held in memory both in javascript, and the browser. Are they decoded to .bmp, .jpg, .png? Can CSS reference them without javascript changing the styles? Can they be cached locally if downloaded directly?
If you needed this for any page that loaded lots of images, all of the above would significantly increase page-load time, and memory usage. Especially on a mobile browser, it would use more resources (hence more battery), than otherwise. So personally I wouldn't like to see this be the future. Maybe just as a fall back, but detection for that might be a little hard.
>> Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it?
Right now, it would appear that the with a hard reload of the demo: http://bellard.org/bpg/lena.html on chromium, the BPG images are initially loaded with the page, then the posts.js file scans through the page's images to find the ones who's src ends in '.bpg', then posts.js re-downloads the same files with ajax, which are then decoded to PNG files rendered in canvas tags with no identifying information.
The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load.
>> Can CSS reference them without javascript changing the styles?
Not from what I can see. The images are being rendered to canvas elements without any identifying information. The decoder will need to be modified to add identifying id's or classes. This again is an easy fix.
>> Can they be cached locally if downloaded directly?
This is what I perceive to be an issue. Try downloading the image rendered to the 5kb bpg example... The image that is being rendered is a 427.5kb PNG and that's for a 512x512 image size.
PNGs aren't lossy... so any difference in file size is going to be the product of rendering size or how much the bpg compression has simplified the source image. ( I'm guessing the file size follows something like a logarithmic curve where it jumps initially based on rendered image dimensions and then approaches a limit as the compression approaches lossless. )
Because of the rendered out PNGs' large file size, I would expect that if you are rendering out large images or a lot of images, you would definitely use more resources than with comparable quality JPGs regardless of whether you cache the BPGs for rendering and you would indeed experience the drawbacks you mentioned in both memory and page-load time.
That being said, this is a cool idea, an incredible proof of concept and I'm very thankful to Fabrice for putting it out there.
A quick glance makes it look like it grabs it by url in the decoder so I think it is doing another download. That said it's probably not too bad since the browser should cache the image also.
I'm a designer, can't read code, and I'm trying to see if I should evangelize this at work. Its better if you could communicate with us non-technical folk and post an answer that the previous guy asked so that we other designers can also understand.
If you want Designers to start using this, then we need a photoshop plugin, an illustrator plugin, a Sketch plugin, a pixelmator plugin. Make it easier for us to export images as a .BGP. If the images are truly smaller without affecting the current user experience of users using mostly modern web browsers, then we're more likely to pick up on using this.
No you don't. You export it as png or whatever lossless format you can and your job here is pretty much done. Then technical guys you are working with convert it or write a script to convert it automatically on upload/download on their website or do whatever they need to do to get lossy image for whatever purposes.
Still, to become truly widespread you need to have support in all kinds of software out there, "everything you need is js plugin" is unreasonable optimism in my opinion. And, anyway, decoding using js isn't fast enough to be one and only solution forever, you need to get to have browser and other software support sooner or later, and for that you need 1 standardized format, not "whatever your plugin supports" as thread-starter suggests.
For the Photoshop file-format plugin, someone should contract out to Toby Thain at Telegraphics who has written a bunch of file format plugins. Or optionally use his GPL'd source code as a starting point if you want to DIY:
What if I use this: http://getbootstrap.com/examples/starter-template/ and add an img tag with a src to a .bgp? Will it render when I refresh the browser? I see that the BPG images are decoded in your browser with a small Javascript decoder. So a JS file is referenced in the HTML, and everything will run ok when I refresh? That's the promise?
Isn't there hardware support for JPEG decoding on most mobile devices?
If so, I imagine it couldn't compete performance and battery life wise.
I remember Mozilla did a software video decoder once in JavaScript.
My guess is that the average mobile CPU speed makes decoding a minor time factor within the process of getting an image from server to the clients screen.
If this is the case, then putting in a hardware decoder would be a needless expense.
I used to own the jpeg decoder at Mozilla, and this was certainly the case last time I looked at it. Even without SIMD, JPEG decoding is pretty cheap compared to most of the things the browser does. I certainly wasn't clamoring for someone to burn JPEG into silicon; I had other things keeping me up at night.
Strange: JPG is, when compressed, order of times smaller than uncompressed, so if the graphic card would accept the compressed image, the amount of used memory bandwidth can significantly decrease. I also believe that the graphic card can achieve more parallelisation and therefore handle much bigger JPG images, which we produce all the time with always bigger cameras.
I believe that some browsers actually keep in RAM all the images uncompressed, that can acually be the reason that makes the potential for optimizations less obvious.
> I also believe that the graphic card can achieve more parallelisation and therefore handle much bigger JPG images
Very large images are fairly rare on the web. In particular phones don't have giant displays, so it's usually a waste of bandwidth to send a huge picture to a phone as part of a webpage. And, speaking only for mobile Firefox at the time I worked on it, we had lots of bigger problems with large images than decoding speed. For example, Firefox would keep the whole decoded image in memory while it was onscreen, even if it was only displaying only part of the image or only a downsampled version of the image. If it's a giant image, the decoded image could use up a large fraction of the device's memory.
I'm also not aware of any major phones with have GPGPUs -- I'm not an expert in this stuff, but I think you'd need that to get any serious acceleration from JPEG decoding.
When transistor size goes down, accelerators which are idle most of the time become cheaper. Your power budget doesn't allow you to run all the chip's parts at the same time anyway.
Maybe it has something to do with the browsers displaying the images progressively as they are loaded. Maybe the hardware decoders don't support that? That's guessed.
this will definitely need to be hardware-supported for decoding. on my phone, the decode time far exceeds the time it would take to serve up a bigger jpg file.
the demos reminded me what browsing on dialup was like. in fact dialup was better cause at least the decoding/loading was progressive/incremental, which doesnt seem to be the case here. i assume it's just the way the decoder is implemented?
I decided to give it a try on a low-spec Android tablet, running latest version of Firefox. Got coloured horizontal stripes instead of a proper picture for every BPG example – and not just once; I was unable to view the images on the tablet.
A native implementation like the JPEG decoder would be fine. The bundled JS decoder implementation is elegant but not efficient on mobile platform (stalling here for seconds on iPad 3 / iOS 8 / chrome while JPEG ones are displayed instantaneously)
With additional effort you can by including the proper JS. However, many sites would find this a benefit rather than a problem, since hotlinking takes away page-views.
You wouldn't really have to change the right click menu. You could put an invisible html div over top the images, and give them the correct link, instead of the raw decompressed image data. So a user would think they are right clicking the image, when really they are right clicking our overlay.
I was ready to pass by this post with a yawn until I saw where it was coming from: Fabrice Bellard. He's no doubt an absolute freakin' genius. And if anybody knows about image conversion, it's him.
Even the things he does just for fun are impressive. Have you ever booted up Linux inside your browser? http://bellard.org/jslinux/
New file format proposals generally aren't news, unless they're already implemented in some popular product. Finding out the latest amazing thing that Fabrice Bellard has been working on, that's news. And that it's already implemented in your browser via Javascript? Priceless.
Sounds like the author lends credibility to the proposal through past accomplishments, suggesting that the project is well planned and executed and thus worth checking out.
At the bottom of the linked article is the answer to your question, with links to more information.
tl;dr (obviously tl;dr): This format is very, very easy to implement despite the patent risk, simply by assuming that any device new enough to be considering including it will have already licensed the relevant patents.
The patents would only cover the implementation that comes with the hardware, not any other software implementation running on it. This means you'd have to use the hardware decoder APIs to decode images, which is less than ideal when you want fast, low latency decoding.
But suing the party doing the infringing would be much harder. They can't just go after Google/Apple/Microsoft because all they're including is a javascript interpreter. They'd have to sue thousands and thousands of sites, most of them for amounts no larger than 1000 dollars.
EDIT: I didn't expect this comment to be so popular and feel like I've hijacked the thread a little - sorry. Feel free to continue at https://news.ycombinator.com/item?id=8706850
I would much rather someone revived the Fractal Image format, which is now out of patent. It's very expensive to encode, but that's nowhere near as big a problem as it used to be. It's very fast to decode, very small, and the files are resolution independent: http://en.wikipedia.org/wiki/Fractal_compression
I was blown away when I encountered it at PC Magazine in the 90s and it seems like it would be very responsive to the needs of today's web.
I'd like to see a modern implementation and some unbiased testing done before I got too excited. From what I could tell, the tech got more hype than was justified by its ability to perform, and I suspect the fact that it still isn't in much use may have more to do with difficult being better at anything in particular than a current existing solution rather than a lack of people interested in it.
(And note my phrasing of "got more hype than was justified by its ability to perform"... it isn't that it has no ability, just that it got more hype than it should have. Same thing happened to "wavelets". Yes, I know about JPEG2000... again, the point isn't that they are "bad" or "can't work" but that they got more hype than their real performance justified.)
IT's not the most competitive in compression or speed terms as far as I know, but the resolution independence is a Big Deal to me. I first saw this technology about 20 years ago and I am still impressed by it because nothing else has delivered that for photographic images. It's like SVG for photography.
At the time, encoding required a) an expensive license and (IIRC) b) an accelerator board if you intended to do anything other than leave your CPU churning overnight - obvious disadvantages relative to formats like jpeg.
you should read the Talk page of the wikipedia entry, where it's obvious there are some misinformed/deceptive folks took control of the page. See the comp.compression FAQ is a much better resource, as is the paper Brendt Wohlberg and Gerhard de Jager, "A review of the fractal image coding literature", IEEE Transactions on Image Processing, vol. 8, no. 12, pp. 1716--1729, Dec 1999 in particular " purely fractal-based schemes are not competitive with the current state of the art"
I'm not talking about the Wikipedia page, which does not in any case make mild claims about the technology. I'm recounting my personal experience of using it and being impressed by the results.
Great find. I worked at PC Mag UK in London at that time. I don't remember if we did a piece on it, but I do remember the oohs and aahs in the office as we zoomed in on pictures of cute dolphins and the like.
Takes about 20 seconds for a 1280x893 bitmap. But the decoded image always looks blurry no matter what settings I use. The original bitmap is 3,349 kB and the IFS file ranged from 17 kB (looking awful and blocky) to 569 kB (looking about half the resolution of the original but not too bad).
Even without optimizations. That page is from 1997. They probably ran this on a 200MHz machine at best. Modern CPUs are 30-50x faster just in terms of instructions per second. Then once you factor in multiple cores, we have desktop machines that are easily 100x faster.
In terms of optimizations we have SIMD and GPGPUs to make it even faster. Not unrealistic to think we could bring that 6 minute figure down to one second... And then, of course, there might be algorithmic tweaks that help us even more. Get 100 people looking at that code, and for sure they'd find ways to speed it up.
After making a few needed tweaks to get libbpg to compile on Mac OS X, I used the compiled bpgenc binary to convert a test PNG to BPG format. I also converted the PNG to a JPEG for comparison purposes. You can see the results here:
I think your page has a bug - the "original png" seems to be encoded in jpg! (The usual jpg artifacts are very visible around the edges.) Thanks for posting the extra example, the bgp looks very good indeed.
I believe that's because PageSpeed is automatically converting the PNG to JPEG on-the-fly before serving the image to the browser, ostensibly for speed reasons. How ironic. ;^)
Would love to have not just the source file but also the output files posted if you can be bothered (im fine with png screenshots if you can't be arsed with actual js setup)
Sure, no problem. I updated my comment above to include a link to all the relevant files. As you'll see, despite the significant differences in file size, there is very little discernible difference in image quality.
Looking at the Lena pictures demo, the extremely low file size comparison at the top shows just how good .bpg is in that use case. That could make for some much lighter websites when used for less important items like image thumbnails on shopping sites, for example.
When the file size gets larger at the end, it looks like there might be a little loss of detail. Ideally I'd like to compare them by switching back and forth using the original image and the .bpg as Photoshop layers...
I notice the container has no ICC profile support. Trivial do add as an extension tag, but should definitely be in the first spec IMO. And if I read this correctly, extension tags are hardcoded as numbers, rather than using a tag name. I don't think that's a good idea.
The BPG spec says, "Arbitrary meta data (such as EXIF) are supported." This isn't good enough. Modern formats need to specify how ICC profile format information is to be embedded, under what circumstances, and smaller space alternatives (similar to DCF and EXIF color space tags). Otherwise this is like JFIF, where it's the ICC spec and not the JFIF spec that describes how ICC profiles are to be embedded. To replace JPEG and PNG, the BPG spec needs to define such things itself rather than deferring the work to others or making it optional. Image color space data isn't optional if high quality is to be taken seriously, and for that matter the encoding of copyright and image provenance information needs to be defined in the spec also.
Yes, that makes it even stranger. Why use an unsigned 4-byte integer when tags are mapped to a number internally. Unless they anticipate to map more than 2^8-1 or 2^16-1 different tags.
Maybe I'm reading it wrong.
extension_tag ue7(32)
...
'extension_tag' is the extension tag. The following values are defined:
1: EXIF data.
PS. I think I understand now. It's just meant as a shortcut. Not sure why this is done when EXIF fits just as well.
Is there a situation where 14-bit sRGB isn't enough? There are a lot of weird color matching issues on the web caused by inconsistent application of ICC profiles to PNG images by different browsers / platforms.
Storing HDR images, where the brightest parts are greater than 1.0. That way, when you later edit the image and adjust the levels, new detail comes into view. OpenEXR is the best we have for this now. It uses half-precision 16-bit floating point color components.
BPG supports CMYK, and to re-render CMYK correctly (on a display, or an inkjet printer) means ICC support is mandatory. Otherwise, there's no point supporting CMYK at all.
sRGB is designed for an 8 bit per channel encoding, so while it makes sense to support 10bpc to mitigate quantization effects of higher compression, it makes little sense to support more than 10bpc unless wider gamut spaces are supported. If the intent is for BPG to replace JPEG in-camera renderings, rather than converting existing JPEG and PNG to BPG, then it needs to support spaces other than sRGB. This doesn't require explicitly embedding ICC profiles but the spec needs to, well, specify at least one way of preserving this metadata. Otherwise there's no guidance for encoding or decoding the information, and then it's lost. And at that point it's a huge regression from what we have now, and thus no point in implementing it.
No doubt Fabrice is very smart. I read about his 4G base station the other day. I'd love to be a fly on the wall while he codes and thinks out these projects.
His accomplishments are impressive: QEMU, FFMPEG, TCC, JSLinux, the list goes on
I have been wishing there was a JPEG equivalent with an alpha channel for like forever. That allows better compositing to arbitrary background images or patterns. Now the question is how long before browsers might support it natively.
Unfortunately given the relationship between Google and Apple and also between Web* and H.26* there is little chance of it going anywhere since without iOS you have nothing.
Its purpose is to replace the JPEG image format when quality or file size is an issue.
Some of the HEVC algorithms may be protected by patents in some countries
There have been some patent disputes over JPEG, but I don't think replacing it with another possibly patented format is a good idea, even if it's technically superior in some ways.
"Most" is a huge overestimation. I don't think Haswell supports HEVC encoding. Qualcomm will only support it next year with the high-end Snapdragon 810, and Apple only recently supported it in the latest iOS devices.
But the vast majority of people right now don't have support for HEVC encoding and won't have for 5+ years.
I can't imagine ever wanting to spin up a hardware HEVC decoder context every time I want to render an image. That would enormously slow down display of a web page with this format.
But with h.264, _codec_ licensing is for non-commercial (and internal business) use only (page 8).
There's no clear statement that HEVC licensing is for any and all purposes, and their use of the term "End user" in MPEG-LA's (non-binding) public material across patent pools is quite inconsistent, so it may mean only non-commercial users.
Given that it's MPEG-LA that we're talking about here, and their history, I assume there will be nasty surprises unless there's hard evidence that there aren't.
Yep, and that bit of JS you are distributing _is_ a decoder. I've been bitten by this before, and it resulted in buying the MPEG-LA a few ferraris a month after they noticed and we were popular while we worked to create an alternate solution.
Hmm, that does make me wonder, actually - as far as I know, you can freely distribute source code for encoders & decoders without having to pay any royalties. Binaries / compiled versions are where the royalties come in. And technically, JS code is source code that gets compiled by the browser... so I'm not actually sure where it falls in all this.
I don't think source code is exempt from patents per se. I think the rule is more like some point in the supply chain has to have a license. It's common to distribute a chip or software library with no license with the assumption that the final product will get a license. But if the source code is the final product it needs a license. IANAL.
Why not use Daala to start from? The overlapping transform probably help especially for still images, and the patent situation is probably at least better.
There's no reason to wait until the I-frame format is finalized - a still image format would probably be a separate codec anyway, so compatibility isn't important.
This definitely looks like it compares favourably against both JPEG and PNG. The test doesn't directly compare against JPEG-2000, JPEG XR or WebP, but the results are more convincing than any examples I've seen for any other formats, and the Mozilla study showed HEVC's format did best on quality metrics.
I hope browser vendors take note. The patent issues are concerning, but if that can be worked around and a new spec designed, then we might just actually have a new image format for the web which really is better than what we've already got.
I'm not qualified to comment on BPG, but this is the first I've heard of Mr. Bellard. I enjoy reading works from minds of this caliber. He seems to be a model citizen for the programming community. Are there others I should know about like Fabrice?
So can anyone talk about the patent issues? I hear there are multiple holders of HVEC patents and they are willing to use them. So if you use this library, wouldn't you be liable?
I'd really like to know that. Because I'd really like to use this.
I've tried it with a picture of mine. The encoding process was painfully slow, but I guess that does not concern the end-user much. The file size went from 1.2M in jepg to 164K in bpg, and the decoding was fairly fast. After turning the image back into PNG the quality seemed OK but that's tough to assess objectively.
The coolest thing is this javascript program that can decode and display the pictures on-the-fly.
Definitely an image format that could save storage space and bandwith, IMHO.
I wouldn't be in such a hurry - right now x265 (as far as I know the best HEVC encoder) still loses to x264 in terms of practical use (you only really get better results by using bitrates so low that the end product will look terrible anyway, and x265 loses hard to x264 quality-wise when encoding at similar bitrate and speed). Considering that x264 is backed by about a decade's worth of development, this isn't that surprising.
There are still patent issues, and you still need to obtain a license to use the software. You will never see this image format integrated into any other open source projects, like Firefox, for this reason.
But you will note that none of those things are "in" Firefox. H.264 support in the <video> tag is implemented via platform-specific APIs (which, for example still don't work on OS X). DRM requires a CDM binary blob, which is again platform specific. You do not have the open-source freedom to port these features to some other platform that does not support them.
1. Why a Subset of HEVC Still Picture Profile? Why not just a use HEVC Picture instead?
2. Since JS sources are readable and being interpreted by VM ( Free Speech ), patents issues should not be a problem?
3. I am assuming the quality of BGP still has Lots and Lots improvement to be made? Since all H.265 encoder hasn't had the time to be tuned. ( Compared to x264 )
I guess the JS is just for proof of concept until support is shipped with browsers etc, but it isn't rendering properly in the stock Android browser (4.2.2).
It gets to Lena's head in the first image, then becomes brigtly multi-coloured, though it looks like the difference between colours right... as if maybe an int overflow in the browser's JS implementation?
That's far from indistinguishable to me. It's actually quite obvious that the BPG is blurring detail at that compression ratio.
Edit: it's particularly noticeable in the wood grain patterns. Also, there's a soft grey dot to the left of the top of the lamp, 100px or so, that's entirely missing in the BPG. There are loads more examples...
Edit again: the color saturation of the rug is pretty washed-out as well.
oops, I wasn't clear... it's meant as a giant background image, and the quality competes with really nasty jaggies that start appearing below ~100KB in size. Nobody will notice wood grain, a few missing details, etc.
The bpg image on your link has much lower contrast. I'm not sure if that can be fixed, but the images are substantially different. I wonder if jacking up the contrast on the bpg might make it look much worse.
I would guess, that decoding speed can become an issue for websites, where many images are already in the cache but are re-displayed rather often...
I write this, because I am building such an application and for now it has many PNGs ... and yes, using a format like BPG would be fine, because I use the PNGs only because of transparency ... but when redisplay is done via a Java Script, I doubt that I could have the same speed. Loading is not so much a limiting factor, since after some time, all relevant PNGs are already in the browser cache.
Can anybody say something to this topic?
Of course, it would be great to have this integrated into the mayor browsers soon ...
Yes but webp hasn't taken off as much as some would like as a defacto standard.
BPG looks good upon cursory inspection. It seems to be more efficient than WebP and supports 42-bit color. It also has .png's features of transparency and lossless compression although I didn't see anything mentioned about animation to replace .gif.
Bonus: since it's based on h.265 hardware support will come naturally and should be just a software update for devices that already have HEVC capability.
Doesn't a JavaScript implementation offset most of the performance benefits? Today we have browsers that are smart about when to cache the decoded image and when not, etc; does that have to be reimplemented in javascript?
From the article:
"Mozilla did a study of various lossy compressed image formats. HEVC (hence BPG) was a clear winner by a wide margin. BPG files are actually a little smaller than raw HEVC files because the BPG header is smaller than the corresponding HEVC header." This study includes WebP.
WebP is in some ways superior, in particular because it has a lossless option like PNG. [Edit: NOPE, I was mistaken.] I think it's kind of a shame that it hasn't caught on all that well. Maybe it's a fantasy, but I'd sure like to consolidate all web images into a single widely-supported and open source format. Ah, to dream...
This is the guy behind Tiny C Compiler, jslinux.org (running Linux in JavaScript in the browser) and Qemu. (And several other interesting projects). This alone makes me have great faith in BPG.
Impressive! Right now it requires a .js decoder, of 75kb.
Assuming a fast C++ decoder instead,(possibly GPU accelerated if the decoding algorithm is well suited for it) and not using JS but what would be the rendering times?
PNG are 4x bigger in his experiments, but interlaced PNG makes it more pleasant to users since it can be rendered progressively, can BPG benefit from such a thing?
edit: Interlacing is also used in JPEG, isn't it ?
It's a tradeoff, as a user, it's obvisouly a win situation when we have a low bandwidth, and as a server it's obviously a win.
Progressive rendering of HEVC is not possible in the same way as it is done for JPEG or PNG. It is also not very suited to GPU rendering.
A C++ decoder with assembly optimizations could easily run four times as fast as the Javascript version. Unfortunately distributing it would not be possible due to patents.
There is also the overhead of using a canvas element as a render target instead of a normal image surface, and using the canvas API instead of just writing color values straight to a buffer.
Unfortunately, a lot of what I do with images is constrained by what can be losslessly embedded in a PDF. Even if no influential organisation is opposed to BPG it will take at least 3 years, I would guess, for BPG to become part of the PDF standard, and then another year or so for it to become reasonable to expect people to have PDF readers that can handle it. However, I wouldn't be surprised to see BPG being widely used in 2020.
Looking at the result and judging is actually the best and most important metric. There are numerical metrics, like SSIM, but they are always worse than human comparison trials. You're optimizing for what looks best to a human in the end, after all.
The problem with human judgement that it's very imprecise. You're unlikely to notice difference between JPEG at Q=90 and Q=95, but you can't say it doesn't matter, because that can cause 40% difference in file size. OTOH objective metrics can easily spot that.
"Looks the same to me" leaves a lot of room for error and you could be unfairly telling one format to save much more detail than the other. And almost by definition these are the details you're least likely to be able to see.
There's also a pitfall of choosing image that looks subjectively "nicer" rather than closer to the original. Codecs that are better (e.g. faithfully preserve noise) may be judged as worse than another codec that's an accidental Instagram filter.
JPEG-2000, for example, is very hard to decode in a CPU. Many implementations take a second to decode an image.
There are two really hopeful things about this new project: (1) by leveraging HEVC, we get cheap (energy efficient) and fast decode on future mobile devices and (2) Since he is demonstrating pretty quick decode in JavaScript now, it clearly isn't a CPU pig like JPEG-2000.
Indeed. Without out-of-the-box support in the major image editors like Photoshop and all the popular web browsers, I don't think we'll see JPEG overtaken any time soon.
Honestly, just last night I was looking and editing photos of a recent trip, and I uploaded them to tumblr to share on a small photo blog I just recently started. After spending some time trying to get the colors right, I realized that tumblr's image compression is god awfully horrendous. I felt so bad looking at my source JPEGs next to the tumblr post that I created a new flickr account right then.
I don't necessarily think JPEG is bad, or that it's even Tumblr's fault that I first thought to share photos there, but if any service/software started using BPG I think I would excitedly try it out.
If Chrome and Firefox implements this, then mod_pagespeed, for instance, can do the conversion on-the-fly also, services like CloudFlare can also do the conversion automatically.
I really dig it, but I'm not yet familiar with BPG. It seems that decoding it would take more processing power, and potentially be slower than JPG. Is this the case? Under the "performance" section, decoding speed was not mentioned.
Yes, it's slower and takes more RAM than JPG. I can see a delay of about a second in my browser. (Edit: I assume my browser is caching the data, but if not, some of that time could be re-downloading the data.)
If the decoder wasn't in JS, that might not be the case. It'd undoubtably be a more efficient native implementation (possibly with hardware support) were it integrated.
[Edit] I had misunderstood the quoted Mozilla performance claims[0] to be related to processing speed, whereas they refer to performance being a measurement of quality. Thanks sp332 for the correction.
Very out of topic but, is lena.jpg still acceptable? I mean, tech industry is getting better at inclusion but come on, are we still using that crop from Playboy?
I'd say it has enough historical significance to still be acceptable. Consider this: every image compression format out there has an example of their work done on the Lena image. The source code for various compression algorithms may have been lost, but the encoded Lena results for that compression algorithm may very well still exist. This means we can compare between compression algorithms of the past quite easily. We dont have to dig up old source code and find hardware that will run it to compare output - we can simply provide the same input that they had.
Regarding the image itself, it's not even a good test image. There are far better images out there that test the robustness of image compression, but those test images haven't been ran though every image processing algorithm since the 1973. Should we change default test images? Yes, but Lena should still be used as well. The historical data it provides is invaluable.
> I'd say it has enough historical significance to still be acceptable.
This sounds a lot like Redskins argument.
> The source code for various compression algorithms may have been lost, but the encoded Lena results for that compression algorithm may very well still exist.
We need to compare a new algorithm to an obsolete one where we don't even have the source code and this is beneficial... how?
Considering that Lenna herself is fine with it, I'd say so. (Unless you want to deny a woman the right to permit the use of her own body for aesthetic, erotic, or academic purposes, which is the logical if ironic outcome of some schools of feminism.)
The problem with the Lenna imagery isn't political correctness, it's the fact that it's a crappy scan from a magazine that always had crappy photography to begin with.
Do you think any of those women would have spared a half-second's thought about this issue? Somehow, I don't think so. I think they were too busy doing science.
I'm not saying all women are crippled by it, because they have to deal with such nonsense while walking down the street every day. But can't we as scientists strive to improve the status quo?
(Shrug) I can point to outraged people "speaking up" about everything from global warming to Jar-Jar Binks. It doesn't prove much, except that some people enjoy a good bout of outrage.
The scientists in the article I linked, on the other hand, aren't speaking up about anything, because they're all dead.
You're implying that because the women you picked didn't speak up and just did their work, that somehow that is the model all women should follow (because Science, apparently). Yet you provide no evidence that they were not affected by attitudes toward women. Just because they did not speak up does not imply there were no negative effects of contemporary attitudes toward women. On the other hand, I have evidence that researchers are affected by it.
Fine, I didn't read it. What is your point? That just because something is worse for one person that we should ignore problems affecting another? That someone else has suffered in the past is not a reason to give up improving the status quo today.
> Unless you want to deny a woman the right to permit
Not doing something you are permitted to do is somehow denying their right to permit? It's nice of her permitting the use, however her permission doesn't force us to use it. By the same logic, it would be perfectly okay use goatse image if the guy permitted it, right?
By the same logic, it would be perfectly okay use goatse image if the guy permitted it, right?
If the ability to represent the goatse image were a critical part of the evaluation process for a compression algorithm, then yes. However, we evolved to recognize and respond to subtle features in human faces, not human colons. So, no, goatse would not be an appropriate reference image.
If her face is the only face that is critical to the image compression analysis, yes, you are completely right.
I have a hard time understanding the knee jerk reaction to the change and the willingness to maintain the status quo. We have nothing to lose if the image is swapped with one that is less ostracizing --which is something Mozilla did in the past. Why defend it?
Technically, the Lenna scan is indeed a bad reference image for numerous reasons, such as being blurry, heavily quantized, and composed of various shades of magenta and purple. Its value is more or less entirely nostalgic.
So it wouldn't be worth defending at all, if it weren't being attacked on grounds I strongly disagree with, by people who I believe shouldn't gain any more influence over our culture than they already have.
> So it wouldn't be worth defending at all, if it weren't being attacked on grounds I strongly disagree with, by people who I believe shouldn't gain any more influence over our culture than they already have.
I'm having trouble understanding what this means, concretely. Do you think it would be a bad thing if computer science became less of a boys club? Or do you not believe that is why people dislike the picture? Who is it exactly that has too much power over "our" culture -- women? Politically correct killjoys?
> So it wouldn't be worth defending at all, if it weren't being attacked on grounds I strongly disagree with, by people who I believe shouldn't gain any more influence over our culture than they already have.
Is it putting words in someone's mouth if said words are their own, I wonder?
He's not saying "I'm disagreeing with you because I dislike you," he's saying "I dislike you because I disagree with your ridiculous PC policemanship and the fact that a lot of people actually take it seriously."
I disagree! You have the cause and effect mixed up. It's normal to dislike certain groups of people you strongly disagree with. For example, I imagine we both dislike gay bashers pretty strongly.
You, on the other hand, were suggesting that CamperBob2 was arguing with you purely because he didn't like you, which would be pretty silly if it were true.
I briefly wondered the same thing.
Tradition would probably be a poor argument for continuing to use it.
But being able to directly compare the results with the lena.jpg results throughout its history might be valuable?
Just one thought: If some woman (or man, or whatever, really) used a similar crop from playgirl in a paper ...
Yeah, sure, from a historical perspective, the situation is not exactly symmetrical, and if it helps with normalizing the situation, maybe Lenna should be banished ... but then again, I would think that if the atmosphere is right otherwise, I doubt anyone would really be bothered by the use of mildly erotic pictures where there is consent from the person in the picture?
I appreciate the historical tradition of using the photo of beautiful young Lena Söderberg as a test image, but it's time to move on. It's fun for us hetero males, but like it or not, this sends a message to young women that they aren't welcome in this field. I wish Fabrice Bellard would have left them out of the demo set.
Having said that, all those demo photos do look good. I was wondering how we were going to see a demo in the browser without built-in support, but leave it to the man who put Linux in the browser to write a decoder in javascript. This is an encouraging project.
> I appreciate the historical tradition of using the photo of beautiful young Lena Söderberg as a test image, but it's time to move on. It's fun for us hetero males, but like it or not, this sends a message to young women that they aren't welcome in this field.
I find your comment a bit strange. I am an heterosexual male and I find this picture utterly uninteresting from a sexual point of view. To me, the appeal of using this pictures is sheer seventies nostalgia... I'm too young to have been alive in 1973 but I'm old enough to remember gawking in awe at the wall of the computer room adorned with output from the first desktop color printer I ever heard of or the first laser printer I ever saw. The example picture used was Lena. The picture reminds me of old computer rooms... I don't even know who the model is and I don't even find her pretty.
By all means use a better picture... But when a Hello World moment is required on a printer, this one is a very strong contender.
It's actually a very good point when you take into consideration the origin of the image. From [1]: “Lena Söderberg […] appeared as a Playmate in the November 1972 issue of Playboy magazine” and it is referring to this particular photo. Article in cyrilic (Russian?) [2] shows what the uncropped version look like. Putting things in context is important.
No, it's not. Because people do not use the second image, nobody sees it until you linked, and it cant "send a message to young women that they aren't welcome in this field".
All this is incredibly unimportant. You just made me waste 60 seconds of my life on a pointless thing and i want them back.
I think people that pretend to be offended by things like this, unwittingly infantilizing the people that they are trying to support, do far more to discourage minorities from tech than pictures of women's faces.
You're assuming that ANTSANTS is generalizing from zero. Since he's linked to one example of one individual that is mature enough to realize that the importance of that common bitmap isn't its origin but what concepts and ideas in the field of image compression those set of pixels have been used to demonstrate, and how those ideas relate to machine learning. Pointers Gone Wild is a great blog, with great technical content, written by someone that is actually accomplishing something because they are fully focused on what actually matters instead of the accidental origin of those pixels.
ANTSANTS' anecdotal evidence serves as a counterpoint to your anecdotal evidence, but you know what they say, the plural of anecdotes is not data. Instead you may want to work from a statistically significant sample size when making your point. If not, don't be surprised when people discount any conclusions you have made based on anecdotes.
> You're assuming that ANTSANTS is generalizing from zero.
No, I'm not. I'm asking: "I'm curious if you're basing this belief on actual information from the people in question, or just your intuition about what they probably think." If he's got statistically stronger evidence than my anecdotes (which are more than two, but yes, still anecdotes), I'd love to hear it! If not, I'm curious what other evidence or argument he has for the claim he made.
Not everything is about gender, sexism, feminism, or chauvinism. There are very few things in the world that are not somehow associated with male vs. female in an objectively equal way. The Lena in question is just an image with a long tradition. Anyone can find and use a male image for his/her own image compression tests if s/he wants to. It's not a statement to use Lena instead.
True, but you still need to balance the relative merits of continuing versus discontinuing the tradition. There is a very real loss from discontinuing the tradition in question without first augmenting references for many of the algorithms that use Lena with other standard reference images. That's a real and immediate loss.
Try a different strategy: offer a better alternative that makes it so practitioners not only don't notices the loss of Lena in common usage, but instead overwhelmingly favor alternatives. Create a better product.
Real comparisons of algorithms do not operate on a single image, but large suites of images, where the results are computed as averages. Changing the dataset by removing one image is unlikely to be a "very real loss."
Alternatives exist, and AFAIK Lena is just used as a "canonical" example to use as a nice picture (like the Zachary Karate Club network).
People are too sensitive. I'm a hetero male, and I don't find the image 'fun' at all... it's just an image. It doesn't send a message to anyone. If anything, I don't really care for it for image algorithm tests because the palette is fairly flat.
No matter how you feel about the image itself, though, there is value in continuing to use it... people are familiar with it, to the point of it becoming almost cliché. This takes the focus off of the image and subject and puts it squarely on the image algorithm.
The smallish downside of continuing with it may outweigh the very small upside. The image by itself might not be a big deal, but we're trying to disrupt the pattern of women being used only as objects, not perpetuate it.
If we used a male model as a photographic test subject here, is that not the sexist objectification of males? Should we use an unattractive person or an animal instead? Are you going to attack the very notion of beauty or the fact that women are the "fairer sex"?
Sure, it could be objectification. It's pretty cut and dried in this case since the image was scanned from a magazine almost at random. The woman had no agency in the decision at all.
Of course I'm going to attack that. Women are required to be beautiful or they are deemed worthless, or failures. So they put a lot of work into it from a fear of failure. Men can be beautiful too, especially to a woman's eye which you've never seen through. If men were made to worry about their appearance as much as women, we'd be "fair" too.
There are predominant gender roles. How can we determine if the predominance is wrong, or just natural? All of this assumes the predominance is wrong. If I go to enjoy a burlesque show (a largely female-dominated event that all consensually participate in), did I merely experience the predominance, or did I also reinforce it? If the majority like something even though a minority do not, does that mean the majority are somehow wrong?
No, the upside of continuing to use it is to show the politically correct bullies that we aren't afraid, and you aren't going to get everything you want.
There is nothing inconsiderate about using the cropped image "Lena". Nothing. It is not an offensive image. Only hypersensitive people who choose to be offended by everything find it offensive, and those people should be fought against, not placated.
Look, you're under no real obligation to stop being an inconsiderate asshole. I'm just pointing out that there are practical consequences.
You don't have to be offended by the image. You don't even have to understand why people are offended, that's fine. But if you don't take other people's feelings into consideration, that's the inconsiderate part.
Other people are going to have different opinions than you do. Telling other people they're not allowed to be offended is why you're an asshole.
I would be an inconsiderate asshole if the picture was actually offensive, ie, if it was goatse, someone in blackface, etc. But it isn't, and unlike you, I have the courage to make a statement about the image: that it is objectively not offensive. There is no one out there who is actually offended by it. They are all people pushing an agenda.
So your argument seems to be that because some people could be offended by it, we shouldn't use it, even though the notion that anyone could be offended by it is ridiculous on its face. So what, then, about things like gay pride parades? People can be offended by those, too. According to your argument, we should end that, too. But I'm sure you'd never advocate for that. You'd say something like "it's their right to be in your face in public". And of course it is, even though it can offend people. But that same argument defends people who'd use offensive images in image processing papers, not just ones which are just a target for politically correct assholes. You only care about people being offended if they're on your side.
Gay pride parades are not bad things, and just the same, a woman posing for Playboy is not a bad thing, and using the cropped image of the face of a woman's nude picture is even less offensive than a gay pride parade. And nobody should be pressuring anyone to stop either of those things.
I'm just saying that anyone who IS offended by it is a whiny, oversensitive asshole who wants to force the world to accommodate them, and that is wrong. Standing up to them does not make me the asshole: babying them makes you the asshole.
Edit: just take another look at the cropped picture "Lena". If your argument is that that is somehow offensive, you are wrong, plain and simple.
You can't understand the meaning of a symbol by studying the symbol. You have to go look at what it means. It's like analyzing a swastika and deciding that neo-nazis aren't offensive. The problem is that only men were part of that project, they treated a woman in an exclusive manner, and now that image is a reminder of that sexist hierarchy.
That's the exact privilege you get to enjoy as a hetero male. You get to ignore things like this when your female colleagues (if you're lucky enough to work with any) have to look at the image and be reminded that many people continue to view them as objects.
Not sure if you're trolling, but I have a spare minute...
- If I post a picture of a cute kitten, does it mean I look at a cat as an object? That I will only under-appreciate all animals because I liked a photo of one?
- If I post a picture of my mother or father, am I objectifying them?
- What if I take a picture of a street performer who's doing some awesome thing and post it... am I reducing them to simply an object of attraction?
I just said it didn't affect me one way or another... that it is just an image. If someone thinks this image means I view a woman as an object, they are projecting THEIR OWN ISSUES onto me. That is the ONLY way that it could be offensive, in that they are choosing to be offended by something that 99% of the population think nothing about.
This isn't just about having a picture. I'm not sure how you got that impression. It's about the context where it comes from and the repeated use of the picture in a scientific context.
If you have a picture of your parents on your desk, that's great and I respect your love for your family. If you keep using a crop of your mother from her Playboy centerfold in the '70s as a test case for your algorithms, and you encourage other scientists to use the same picture, I might be a bit weirded out.
If you keep using a crop of your mother from her Playboy centerfold in the '70s as a test case for your algorithms, and you encourage other scientists to use the same picture, I might be a bit weirded out.
>If you keep using a crop of your mother from her Playboy centerfold in the '70s as a test case for your algorithms, and you encourage other scientists to use the same picture, I might be a bit weirded out.
And who wouldn't be! But that begs the question, is there a son or daughter of Lena Soderberg who is also a researcher or software engineer working in image compression algorithms?
Sure. This picture was painted by Dali, inspired by a Scientific American article about the minimum number of pixels needed to recognize an image. He was making an artistic statement that has a direct connection to Fourier analysis (and if you read the context article that image came from you might know this). This is a painting whose context is "fine art" (i.e. you can have tasteful nudity). That is a different context from pornography, whose purpose is sexual.
You clearly do not understand how the context of an image matters in interpreting it.
>This picture was painted by Dali, inspired by a Scientific American article about the minimum number of pixels needed to recognize an image. He was making an artistic statement that has a direct connection to Fourier analysis
Blah blah blah blah blah blah blah blah... The Lena image contains a nice mixture of detail, flat regions, shading, and texture that do a good job of testing various image processing algorithms. It is a good test image. It is used by thousands of researchers in the field since image processing was a field.
So, your image isn't "sexualization" because Dali and "fine art" ?
>You clearly do not understand how the context of an image matters in interpreting it.
You cannot articulate a difference between Lena and the Dali that doesn't rely upon subjective opinion.
> So, your image isn't "sexualization" because Dali and "fine art" ?
Yes, there is such a thing as tasteful nudity, and pornography is generally not. This is why our society allows children into art museums but not strip clubs. What is so hard to understand about this? Context is subjective, but there are agreed-upon standards for professionalism. Just because the standard was different fifty years ago does not make it a good idea today. If you can't think of any "traditions" from fifty years ago that professional scientists unanimously agree are wrong today, then you're quite ignorant.
> Blah blah blah blah blah blah blah blah...
Clearly I am the one failing to articulate things.
Why? It's the picture and not the context. If it wasn't posted here on HN, it wouldn't have seen it.
>If you have a picture of your parents on your desk, that's great and I respect your love for your family. If you keep using a crop of your mother from her Playboy centerfold in the '70s as a test case for your algorithms, and you encourage other scientists to use the same picture, I might be a bit weirded out.
Do you know on how many portrait photos of your co-workers they wear pants? Do you think it is important they do? Also get weirded out, that's your problem. Do you know how many people get weirded out of you because you browse HN?
Why don't you find a set of great test images (under suitable licence) then run those through the wide variety of image formats at different settings, and host it all on a website? (Put a few ads on it and you have nearly passive income, if the hosting isn't too much)
Did you read the article? There were _several_ great test images used in the Mozilla study under suitable licenses, and Bellard did test with some of those. The Lena picture here wasn't particularly scientifically useful, it was presumably just used out of a sense of tradition. (Mozilla didn't use it.)
If it matters so much to you, take that image set and do exactly as DanBC suggested.
Create a site with all the different image formats out there with a larger test set.
Be willing to take matters into your own hands and change the norms and traditions in that field of study. The best way to accomplish that is by offering something better. I would say that a wiki with many test images for many algorithms is something better. If you do an good job, people will adopt your approach and tradition will change. Complaining on HN isn't going to change tradition.
Introducing new ideas usually is usually more successful long-term approach than "book burning" because you disagree with the content.
What do you know, there are other attractive women in those photosets, including at least one that appears to be wearing roughly as little as Lena. It's almost like our brains are wired for facial recognition and thus attractive faces are good test subjects for image compression algorithms or something.
Sounds like we agree, then -- there are enough other images with all the properties of the Lena image that make it useful for image-compression tests that there wasn't a scientific reason to use the Lena one in this analysis.
But none of those other images have been used as widely for as long to provide the same utility for comparison.
Getting the equivalent for all other papers involves getting the source code for all the other papers, and running those algorithms against these other images and making those images easily discoverable by someone who might come across these other papers (they are unlikely to contain links to your newly generated set).
What you're essentially advocating is reducing the available comparative evidence in an entire field of study because some people object to its origin, many of which don't even work in this field of study.
I'm sorry, but when you can't even admit that eliminating this image from use might have negative consequences from a utility point of view, it makes it very hard for others to accept your position.
Losing a common point of comparison in a field of study working on optimization problems is a step back. If you advocate for "diluting" the image by getting other reference images in common use by practitioners, then I can back that up. That approach actually balances the concerns of both sides and generally enriches the field (more common reference images can only serve to aid in objective and subjective comparison)
The fact that you call the uncropped image "pornographic" (which, yes, it technically is) when Playboy centerfolds are rather tame by modern standards kinda hints at the real problem here: the boring old American prudishness that has been masquerading as feminism as of late. I sincerely could not care less if Bellard had used Billy Herrington's toned ass as a test subject. The sooner that our society can get past this ridiculous fear of sexuality and the human body, the better.
Perhaps not coincidentally, Bellard is from France, a culture much more accepting of nudity and sexuality than ours. I would not be surprised if he had simply not considered the possibility of prudes across the pond getting outraged over such an innocuous thing.
Now show me a picture of a man from that dataset that could possibly be construed as sexual.
This is not a matter of prudishness. I would be totally fine (see my other comment in this thread) if researchers used both male and female crops, but they don't. So to make your point you need to show me all of the male French researchers who are accepting of male nudity in their image processing research. I would be very surprised if you could find me a single one.
>Now show me a picture of a man from that dataset that could possibly be construed as sexual.
>This is not a matter of prudishness.
There seems to be a contradiction here.
>I would be very surprised if you could find me a single one.
I agree, not because I think male French researchers would give a rat's ass about the cropped head of a naked guy appearing as a test subject, but because I doubt any would be foolish enough to poke the proverbial hornet's nest and incur the wrath of self-righteous west coast white guys tweeting on their iPhones.
You're missing the point, which is that it's not the specific image, but that testbeds use suggestive photos of attractive women and not men. You want people to feel free to use nudity or suggestiveness. Fine. I want them to be equal about which suggestive photos they use. As in not all women.
And now you're saying that French researchers don't care, but they do because they don't want to anger Americans? (And somehow they're all white, live on the west coast, and have iPhones?) What a crazy web you're weaving.
>This is not a matter of prudishness. I would be totally fine (see my other comment in this thread)
You mean this one? "Sexualizing women has nothing to do with image processing research." How positively libertine of you.
>You're missing the point
And you're missing my point, which is that if you really weren't a prude, you wouldn't care either way. Straight men like pretty women, straight women like handsome men, gay men like handsome men, gay women like pretty women, some people like some combination of the above, some guys 40 years ago liked a pretty woman, who gives a fuck? Stop being offended by extremely tame displays of sexuality.
>And now you're saying that French researchers don't care, but they do because they don't want to anger Americans?
You city slickers don't seem very good with jokes, do you?
I'd tell you to "lighten up" but I forgot that's code for "long live the patriarchy."
I open a men's magazine and see photographs of women.
I open a women's magazine and see photographs of... women.
These magazines exist because people are buying them. WOMEN are buying them. I don't see many men on the editorial boards of these womens' magazines, pushing for more attractive women in the magazine in ever-more-scantily-clad garb.
What do I conclude, other than that a lot more attention seems to be being "naturally" paid to women in general, especially in a superficial context?
What do I make of the fact that more than double the number of women are bisexual, than males are? And thus, a significantly higher percentage of people of all sexes find the female form interesting?
Women: The cause of, and solution to, all the world's sexism
You are either subtly trolling, or have an incredible amount of cognitive dissonance going on here. You both objectify her by using those adjectives ("beautiful, young") AND THEN go on to state that use of a female model is sexist. Is use of a well-dressed male model sexist? If not, then your entire PREMISE is, in fact, sexist! Not to mention this photo is ENTIRELY asexual. Are you suggesting we avoid use of human models entirely to dodge sexism? Good luck with that.
90% of all photos posted on the internet contains a human face. Having a human face as a test picture makes perfect sense and this one has been used forever so it's a good benchmark that people can compare and relate to. It's not like she's totally naked or anything like that either.
What about introducing a new male equivalent image of Lena instead? This approach would at least balance things out while maintaining an image that has become a standard to compare things to for a long time.
If I were someone working on image compression techniques I would probably have seen many many algorithms and their output using that image so when I see a new algorithm and a new Lena, I might look at the results and think "Hey, this is similar to this other approach I am familiar with"
So many photos taken on any given day are photos of people, so it's simply not practical to eliminate a human subject from test images. If we're going to have an image of a human subject, that person is going to have to be somewhere on the gender spectrum. More data (images of two people) is preferable to no data (no images of people to avoid the risk of offending anyone)
There's a difference between using a picture of a human face because we've determined it's useful for the test at hand, and using a 1970s Playboy scan because that was the most convenient thing for early computer-graphics researchers in the 1970s.
In particular, the (appropriately-licensed) Kodak image set used in the Mozilla study includes multiple pictures of women, none of which are Playboy scans. The complaint is not that there's a picture of a woman, it is that _this_ particular picture keeps being used despite no particular scientific reason why it's optimal for comparing graphics formats.
So the only real contention people have here is the source publication of the original image, right? Because AFAICT, the cropped image (as it's always been used in practice) is nor more or less offensive that kodim04.png from the kodak set.
Furthermore, why does the licensing matter? Near as I can tell every use of Lena, except for by a for-profit company, constitutes fair use. The image, every time I've seen it, has been used for non-profit educational work. It's never reproduced in its entirety. The use of the image for this image compression purposes has no impact on the original market for which the image was originally created. Does this not meet the requirements of fair use?
That all said, I agree that if their is a better images available for this purposes, those should be used as well, but that is an entirely separate issue from whether or not Lena should or should not be used. The happenstance provenance of the image is really the only controversial detail, and if we go back to the history of why it was used it was mere chance:
Alexander Sawchuk estimates that it was in June or July of
1973 when he, then an assistant professor of electrical
engineering at the University of Southern California Signal
and Image Processing Institute (SIPI), along with a graduate
student and the SIPI lab manager, was hurriedly searching the
lab for a good image to scan for a colleague's conference
paper. They got tired of their stock of usual test images,
dull stuff dating back to television standards work in the
early 1960s. They wanted something glossy to ensure good
output dynamic range, and they wanted a human face. Just
then, somebody happened to walk in with a recent issue of
Playboy.[0]
Put yourself back in 1973. Imagine all the different sources of high quality glossy images of a human face with high dynamic range you might have easy access to 41 years ago. I have a hard time thinking of content that would have been available at that time that would have rivaled Playboy. I have no qualms with people judging things from today in todays terms, but presentism [1] tends to rub me the wrong way. If you want to judge something, don't do so anachronistically.
Anyways, I want to re-iterate my main point, which you did not address:
If I were someone working on image compression techniques I
would probably have seen many many algorithms and their output
using that image so when I see a new algorithm and a new Lena,
I might look at the results and think "Hey, this is similar to
this other approach I am familiar with"
There is value in consistency/continuity. Starting to use the image of Fabio Lanzoni like Deanna Needell and Rachel Ward did is a "lossless" approach of dealing with the controversial provenance of Lena.
I find the argument that there would be a lack of high-quality images in 1973 utterly unconvincing. Life magazine or national geographic could have been used. It was just a historical accident, and contrary to what you claim, I do not believe there is a pressing reason to keep using the exact same image, it's merely a relatively unquestioned tradition.
Almost none of the images from life magazine are studio images. The quality of the images vary greatly depending on the equipment used by the photo-journalist (often viewfinder Leicas not large format Hasselblads).
National Geographic has been printed in a format that is approximately have the surface area as Playboy. From a cursory search of NG covers from 1973, the images aren't the same quality as those achievable with studio photography equipment available at the time.
> It was just a historical accident, and contrary to what you claim, I do not believe there is a pressing reason to keep using the exact same image, it's merely a relatively unquestioned tradition.
Many people (including myself) do not believe there is a pressing reason to not keep using the exact same image. I do think there is good reason to publish research with additional test images including the Kodak set linked to above. "Dilution" of the image would achieve the same goal some are advocating here.
Lastly, I find the following heuristic valuable:
function hasValidOpinion(person) {
return person.hasPublishedContentInField();
}
Near as I can tell from the profiles of people participating in this bikeshed, that function produces false for you, geofft, loudmax and myself. The truth is that none of our opinions are relevant here since this isn't our bikeshed to paint.
The easiest way to break from this tradition is to produce novel research in the area of image compression and publish papers without using this image as a reference. Feel free to publish a paper without it if this matters so much. In the meantime, it's not really fair to be out there criticizing those who are from the comfort of your armchair.
I'm not convinced that other magazines couldn't have provided an image of similar quality, your arguments are rather hand-wavy. The notion that only a person from the same field can have a valid opinion on this is frankly ridiculous. It's plainly ad hominem / argument from authority. I don't care to convince you that we should change the practice of using this picture, but I'm curious to know why you would think we should NOT change it, given that there happen to be people who believe that we should.
Find one. I've been through a fair amount of old periodicals from the 60s and 70s and I'm at a loss to think of something comparable. A copy of Vogue (est 1892) or W magazine (est. 1972) would probably have comparable images, but would probably not have been readily available at the time to the demographic doing this kind of research.
We should not change it for the reasons I made in several sibling comments: we lose a common point of comparison.
You can dilute it's relevance by providing many alternative reference images for many algorithms and popularized those alternative reference images. No one in the field is going to complain about having more common reference images, but they sure as heck are going to see you as "book burner" if you trying to eliminate the one common image without first providing alternatives. Merely stating there are other lossless images is not sufficient. You need to provide those same images after having been processed with every relevant algorithm someone might need to know.
How about you start off by doing this work for Bellard. Take the Mozilla set, run them through BGP and send the images to Bellard for inclusion on his website. Enrich us. Don't make us poorer.
> The notion that only a person from the same field can have a valid opinion on this is frankly ridiculous. It's plainly ad hominem / argument from authority.
The notion that someone uninvolved can have an opinion and expect others to shoulder the burden of conforming to that opinion is even more ridiculous.
>A 2012 paper on compressed sensing by Deanna Needell and Rachel Ward used a photo of the model Fabio Lanzoni as a test image to draw attention to this issue
Well, now that they have done it, straight males can "try on" what the oppression of Lena must feel like for women:
So everyone, please respond:
Now that there's an "attractive" man in use for image testing, do you feel repulsed or discouraged that they would sexualize/objectify a man like that?
Do you feel pushed away from this industry?
Personally, this exercise is helping me see the light of the "are we treating women as delicate flowers who can't handle it" viewpoint. That image of Fabio is not threatening to me. Anyone who tries to tell me it is threaten, I think is being overly sensitive.
I'm utterly comfortable with people expressing this level of sexuality in the academic/public area. It's more akin to a "schoolkid crush" than to strip tease.
I just stopped reading after I got to that image. Why, with all the photos you could possibly choose, use a sexually suggestive one? And one whose context is the kind of boys-club software engineering we should be doing everything to get away from. Sigh.
Also, looking at the other comments, the fact that you happen to be fine with that image is neither here nor there. It certainly doesn't cancel out the fact that I'm not.
I think everyone is forgetting the fact that the uncropped photograph is pornographic. So the rule should be "If you use Lena, use a similarly cropped picture of a nude male model."
People aren't forgetting. It's a disgusting "in" joke. The entire point of including it is because it's pornographic.
Disappointing, but unsurprising, to see HN defending the use of literal pornography in a professional setting. I thought we moved past the Ruby on Rails jerks defending porn in a professional setting as harmless fun.
What's needed is a compression method that doesn't introduce artifacts on hard edges, as JPEG does, but is otherwise no worse at compression than JPEG. Then we wouldn't need to do some things in JPEG and others in PNG, and we'd be spared the pain of JPEG screenshots. Much better results on the Tecnick image set (which is mostly hard edges) would indicate one had been found. The results only indicate modest improvement in that area.
In particular, look around her face, eyes, and the background. The JPG is not just worse, but in fact very worse.
A more serious flaw is that it doesn't support animation. It doesn't need to be a video format. It just needs to be able to play a sequence of frames in succession. This is as easy as including a header that specifies how many frames are in the animation and the duration of each frame, followed by the image data itself. The fact that PNG doesn't have this has plagued the format since the internet became popular.
That may seem like "a video format," but it's not. Video decoders optimize for inter-frame compression, not intra-frame compression, so it's a different problem altogether. BPG doesn't need to do everything, but it should probably have basic animation.
That depends on what you mean by "worse" and "very". I think for most use-cases, those differences are not something likely to be noticed by the majority of users.
Again, JPG is not merely worse, but very worse. In fact, JPG makes it look like she's wearing a hat that's made of crosshatch material at the top, when in fact the top is composed of rings of fiber, not crosshatch.
So we don't like HVEC due to patent worries? Fine, we can swap in another format and use the same technique.
We don't have an I-frame format for Daala that's finalized yet? Fine, we can use work-in-progress. The format does not need to be finalized. If you update it, you rebuild your images and bundle a new JavaScript decoder.
The ability to ship media along with a sandboxed, runnable decoder is awesome, and I'm surprised it hasn't caught on until now. I remember Google a while back implemented their own "video" codec in JavaScript using JPEGs and primitive inter-frame processing, exactly because there wasn't a universal video codec format they could use.