Last modified: 2013-10-01 03:07:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19505, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17505 - No High Dynamic Range Image (HDRI) file formats allowed on Commons
No High Dynamic Range Image (HDRI) file formats allowed on Commons
Status: NEW
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: multimedia
  Show dependency treegraph
 
Reported: 2009-02-15 13:37 UTC by proxlrbar
Modified: 2013-10-01 03:07 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description proxlrbar 2009-02-15 13:37:13 UTC
Currently, open HDR image file formats (Radiance HDR, OpenEXR) are not supported on Wikimedia Commons (see http://commons.wikimedia.org/wiki/Commons:File_types). It is important to allow users to upload images in one or both of these file formats, for the following reasons:

* HDRI is a rapidly developing field, and it is expected that HDR images will become far more common in the following years.
* To my knowledge, there are no HDR images on the web which have been published under a free license, nor are they allowed by Flickr. Allowing HDR images would be a great opportunity for Commons to establish itself as the main source for them.
* At the moment, we only have a category for tonemapped HDR images (http://commons.wikimedia.org/wiki/Category:HDR_images). Most of these images were obviously generated using a bad tone mapping operator or simplistic image processing techniques, as can be seen from the halo artefacts. With HDR images, users could not only recover the full dynamic range of photos and computer graphics, and change the exposure without any loss, but also use any tone mapping operator they want.

One issue is the preview/downscaled image to provide. I suggest that the preview/downscaled image be generated from the HDR image using a robust tone mapping operator, such as Ward's histogram adjustment technique (http://radsite.lbl.gov/radiance/papers/lbnl39882/tonemap.pdf).
Comment 1 Brion Vibber 2009-02-17 07:04:35 UTC
A few background items to fill in:

* Any standardization/patent issues?

http://en.wikipedia.org/wiki/OpenEXR indicates it's an open file format with open source implementations, and doesn't mention any patent issues. http://en.wikipedia.org/wiki/RGBE_image_format seems a little less clear on standardization or current usage, and again no mention of any patent issues (either positive or negative).

* Recommended standard software for working with it?

* Any performance issues with rendering to in-browser view?
Comment 2 proxlrbar 2009-02-17 20:17:28 UTC
1) I am not aware of any patent issues with either the two file formats or tone mapping operators.

2) If by "working" you mean libraries for reading the file formats:
* You don't need any for RGBE because the file format is trivial.
* There is a library to read OpenEXR. The OpenEXR home page [1] says "ILM has released OpenEXR as free software. [...] The OpenEXR software distribution is now licensed under the modified BSD license"

If you mean libraries for tone mapping:
* qtpfsgui [2] is a software under GPL which includes different tone mapping operators, but the implementation may be of doubtful quality.
* Many of the so-called "global" tone mapping algorithms such as [4] or [5]/[6] are easy to implement on your own because they just apply a logarithm-like formula over each pixel. The source code in [6] has very liberal licensing terms.

If you mean programs to display HDR images, there is HDR View, OpenEXR Viewer, Jahplayer or Adobe Bridge, to name a few.

3) Global tone mapping algorithms are quite fast because they work independently over each pixel, and a good compiler can make use of SIMD. According to [3], Ward's scale factor [4] is the fastest, and took ~1 second to render a 1,600 x 1,200 image on an Apple iBook G3 running at 800 MHz.

[1] http://www.openexr.com/
[2] http://qtpfsgui.sourceforge.net/sfproject.php
[3] Erik Reinhard et al.: "High Dynamic Range Imaging", p. 358. Morgan Kaufmann, 2006.
[4] Greg Ward: "A contrast-based scalefactor for luminance display", in "Graphics Gems IV", pp. 415-421. Academic Press Professional, 1994.
[5] http://www.cs.utah.edu/~reinhard/cdrom/source.html
[6] http://www.cs.ucf.edu/~reinhard/Reinhard02/
Comment 3 Rd232 2012-07-11 20:14:52 UTC
It's been three years, and HDRI is becoming more and more common (some cameras even do it automatically now). Can we restart this discussion?
Comment 4 Brion Vibber 2012-07-12 19:38:51 UTC
Please do -- this is the sort of specialized area we can hopefully get a smallish project moving. :)

Is OpenEXR standard/common enough at this point that we could mandate it as "the" HDR format? If so we can probably go with that.

There are a couple levels of support we can offer:

1) very limited -- allow uploads but don't show them inline. (Useful to upload "original version" files). Need to be able to verify file type, not much else.

2) JPEG thumbnail support -- convert to non-HDR JPEGs for inline display. Need to be able to extract image width/height and use either ImageMagick or other software to do basic conversion. Downside: no actual HDR view inline, you'll be clipped.

3) Plugin view support -- allow using browser plugins (??) for native HDR view. Not sure what's available or what that implies.

4) JavaScript-based partial HDR viewer with controls.... not sure how much sense this makes, but could allow for viewing and live adjustment of the dynamic range without browser plugins. :)

Thoughts anyway...

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links