openexr-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-user] Questions for more experienced users


From: Michael Wolf
Subject: Re: [Openexr-user] Questions for more experienced users
Date: Mon, 19 Feb 2007 01:10:13 +0100
User-agent: Opera Mail/9.20 (Win32)

On Mon, 19 Feb 2007 00:53:17 +0100, ben Grossmann <address@hidden> wrote:

> Hello all!

Hi Ben,

> http://ls.cinematography.net/read/messages?id=124861
> In the "cml-2k-444" forum.

I might jump over there as well, but I've got a few comments to your post I'd 
like to add here first:

> <QUOTE>
> The format can contain multiple resolutions of an image.  Ignoring
> file size implications for a moment,  it seems to me that the
> advantage of having multiple resolutions in the same format, is to
> allow them to play back faster on machines that can't handle the full
> resolution.    As it stands now in the spec, each file can contain
> variations on resolution.

 From what I've seen, not quite.

The variations in size you seem to refer to are the Mip/Rip-maps, those are 
targeted for 3D applications.
They basically contain scaled down versions of the main image, in the case of 
mip-maps scaled down by a factor of 2 until a size of 1x1 pixels is reached.

> If those resolutions can be pushed to the
> player individually, then that solves the "realtime" conundrum.

The problem is that none of the lossless compression modes are designed for 
playback (too slow), while the (new) compression mode that is fast enough is 
lossy.

> Machines that need to see it realtime, but can only support it at
> half-res, get it that way.  Machines (Probably with fast raids and
> good graphics cards) that can support playing it back at full-res, can
> do so.  I do NOT know that this is actually the case, so it would be
> good to hear from a developer who knows.

I'd probably prefer JPEG2000 for that kind of application. Especially since in 
JPEG2000 decoding is progressive. Consecutive higher quality "resolutions" are 
built using the (already loaded) lower res image data. This allows you to 
change the quality during playback to adapt to the current i/o situation (in 
theory, I have to admit I haven't tested that yet).

OpenEXR would require you to load a different set of data from the same file to 
access the higher resolution, discarding the lower res you might've loaded 
previously.

> The format can support Scanline Images AND Tile-based images.  And it
> supports a function to adapt compatibility in case the player doesn't
> support one or the other.

Almost. The library doesn't adapt, the player chooses which interface it uses 
to read the images.
The scanline interface can read all types, but only as scanlines.
The tiled interface can only load tiles, but has access to the data as tiles as 
well.

> This way, you don't have to load an entire
> image just to see a specific region at full resolution.

Again, JPEG 2000 does that as well.

The only issue with JPEG 2000 is the slow decompression and no HDR capabilities.

> </QUOTE>

Not that I'm advocatng JPEG 2000 for all cases. I love EXR for how it works and 
what it does, it is a great image format, but not (yet) for what you've 
mentioned above.

Feel free to correct me and flame me off the list now ;)

Cheers
Mike

-- 
db&w Bornemann und Wolf GbR
Seyfferstr. 34
70197 Stuttgart
Germany

tel: +49 711 664 5250
fax: +49 711 664 5251
http://www.infinimap.com
http://www.exrtrader.com

skype: lupus_lux
icq: 252887990

VAT-Id:  DE 232958645




reply via email to

[Prev in Thread] Current Thread [Next in Thread]