Dome Master Show File Format 1.0 - Sec.II - Dome Master Working Specification

II. Dome Master Working Specification

The “Dome Master” refers to the individual images projected by the fulldome system. For purposes of this working specification, only circular dome masters (i.e., a square source frame) are considered.

1.     Geometry – equidistant azimuthal “fisheye” render representing up to full sphere with bottom of the frame representing the front bottom of the dome screen, and the right and left hand sides of the dome master corresponding with the respective right and left sides of the dome to a viewer sitting at dome center within the theater. Top and sides of polar image are tangent to edges of image frame.

2.     Recommended file formats:

a)    sequentially numbered lossless files — e.g., PNG, TIFF or TARGA with RLE compression

b)    other sequentially numbered files — e.g., JPEG at highest-quality setting

3.     Recommended file name format — e.g., “Name_00001.jpg”, “Name_000001.jpg”

4.     Recommended folder name format “filename_000001_010,000”

5.     Color Bit Depth — e.g., 8, 10, or 12 bits/color

6.     Frame Size, frame must be square, with standard diameter resolutions of 720x720, 1024x1024, 1536x1536, 2048x2048, 3200x3200, 3600x3600, 4096x4096, 8192x8192

7.     Recommended frame rates

a)    30 fps or 60 fps

b)    other frame rates — 24 fps, 25 fps, 29.97 fps, 30 fps, 48 fps, 59.94 fps, 60 fps

8.     Alignment Frames — set of standard frames included in dome master that establish synch and test proper geometric alignment, gamma, color balance, etc.

9.     Other design recommendations:

a)    Unidirectional “Safe Action” area approx. ±50° longitude (measured from dome front/center), and ranging from 10–60° latitude (altitude)

b)    Nominal camera tilt of 15° great circle (cf. reference frame)

10. Exterior to active pixel area:

a)    region colored black (except for time and frame data)

b)    user-defined show name, timecode, and frame number text

c)     recommended arrangement: timecode (top line), frame number (second line), and frame rate (third line) in upper left-hand corner, with show name in upper right-hand corner[RJW1] 


 [RJW1]I re-inserted the recommended arrangement because it really does make sense. :)

Views: 3062

Attachments:

Replies to This Discussion

>6.     Frame Size, frame must be square, with standard diameter resolutions of 720x720, 1024x1024,1536x1536, 2048x2048, 3200x3200, 3600x3600, 4096x4096, 8192x8192

Shouldn't there be a 6k resolution option?  Would that be 6144 x 6144?

ed

Let's include all multiples of 1024, multiples of HD, plus outliers.  For example:

- 1024, 2048, 3072, 4096, 5120, 6144, 7168, 8192, 9216, 10240, ...

- 720, 1080, 1440, 2160, 2880, 4320, 5760, 8640, 11520, ...

- 1536, 3200, 3600, 6400, 7200, 12800, ...

Give the projector-makers an extensible standard framework.  Otherwise they'll just keep inventing their own proprietary dimensions.

  • Seems like there should be a separate section for "directory structure and file naming" that supports/reinforces the metadata spec.  Naming conventions can be moved there, leaving this section completely about the image file, sizes and layout.
  • Item 7 doesn't really belong here.
  • Item 8 needs more detail.  Can we create/share standard images for this?
  • Item 10c is the actual standard.
  • Item 10 missing content producer and copyright information.  Perhaps a space in lower-right corner for content producer's name, watermark, and copyright info.
  • Item 9 is more of a recommended style guideline, not really a standard.

RJW - can you share the XML wrapper you've developed?

Actually, I need to nab that file from our engineering team, but yes, we can share it!

Ken Scott said:

RJW - can you share the XML wrapper you've developed?

As per my comment about “recommended” above, I think we should cite recommended resolutions and other resolutions… A laundry list of numbers seems unappealing in a standards document.

My $0.02 would be to have 1024, 2048, 4096, and 8192 be the recommended (with maybe 3072 and 6144 in there, too), with all others lumped into an “other” category.

Ed Lantz said:

>6.     Frame Size, frame must be square, with standard diameter resolutions of 720x720, 1024x1024,1536x1536, 2048x2048, 3200x3200, 3600x3600, 4096x4096, 8192x8192

Shouldn't there be a 6k resolution option?  Would that be 6144 x 6144?

ed

Item #6 is tricky I think.  I think it's appropriate to designate that the domemaster must be square but the notion of a "standard diameter" is somewhat dependent upon what current projection technology.  It's fine to stipulate some multiple of 1024 but there are projectors being sold now that run at 2560.  If we include an "others" category as a catch-all for resolutions that are not some multiple of 1024 then I fail to see the point of itemizing any sort of standard size.

This is just maybe my natural tend to push authority limits, but when you say something like "recommended" file formats my first instinct is to consider what other formats might fit this description(in this instance, a BMP for example) that are not necessarily recommended.  Why not simply settle upon one lossless and one high-compression format?  

For item 4, why limit it to 12 bit color?  Shouldn't color-downsampling be handled by the receiver when they prepare the frames for playback?  

For item 6, I would suggest including all powers of 2 as a catch all, if anything.

For item 8, I submit that should be a standard "leader" type set of frames that are required for inclusion if you want to claim to be adhering to this standard.

For item 9, I would call this a "title safe" and not dome safe, since the main issue concerning standards will be with cut-off in domes that display < 180°.  Anything else is less a standards issue and a production design issue.  

For item 10, this is where I would put a "dome safe" buffer zone of at least 10 pixels from the perimeter of the image to any text or image.  

How do you plan to incorporate dome tilt issues?

I would like to oppose the requirement of item 9.b (nominal 15° tilt).

It might be wise to add a flag stating the recommended playback dome tilt since this clarifies the intended use of the media. I see a difference especially in the sweet spot description as soon as you get to flat domes.

Likewise, a flag describing the geometric compression of the footage will be helpful. This again affects the title safe areas and sweet spot.

Should there be a descriptor dealing with rear truncation?

When delivering a domemaster in a format that holds an alpha unless the show needs this information for compositing during playback it seems that these extra bits should be dumped. Especially as we reach for higher frame rates. By default, this data piggybacks along as a solid channel... just a thought.

I agree that listing a specific set of resolutions is troublesome.  For instance, there are a growing number of 2400 x 2400 systems out there as well as 1600 x 1600 systems.

These new formats are driven by new projectors such as JVCs 4K machines. What is the purpose of listing these resolutions?  Is it to guide  fulldome show producers?  Well that will always be a moving target as new projectors are developed and projection technology evolves.  I suggest that you either drop the resolution list or simply say: "Frame Size, frame must be square, with standard diameter resolutions to be determined by the playback theater's fulldome projection resolution. For instance it can vary anywhere from 720 x 720 to 8192 x 8192"  

There are many issues here.

For instance, the very definition of fulldome is suspect.  Are we talking about a given resolution projected on a standard 180 degree by 360 degree dome (equidistant azimuthal “fisheye” render)? If so, most large theaters today are partial dome sections (160 degree or 170 degree dome sections or some variation thereof)  If you project a 180 degree dome image onto 160 degree dome, those pixels are no longer the same aspect ratio and vary greatest as you near the horizon.  If a theater is not doing this unintended image dimension compression, then they must crop the image. I don't know of anyone who has a 160 degree dome that is cropping off the bottom 10 degrees of their 180 degree equidistant azimuthal “fisheye” render.  So the resolution issue is in reality a bit tricky.

All good points by Philip, Tom, Jonathan, Michael, Ryan, et al.

The core of what we're debating here is this:  who gets to make it fit?

As a content producer, I want to produce one high-rez version, and let the venue morph the picture to fit their screen - just as they do with the audio.  Conversely, as a content consumer I want the highest possible quality tuned to my specific system.  Of course, it's not fair to either side when the work is shoved over at them.

The core purpose of this standard is to enable automated communication of detailed technical information that describes a big blob of digital data.  Some of what we're doing here is restricting the possibilities.  Some restrictions or guidelines are fairly obvious, and we'll find it easy to agree on them.  Others will generate controversy, because people have a vested interest in (and darn good reasons for) supporting one metric over another.

Remember that at the end of the day it's all done in software, both realtime and non-realtime.  I don't see any technical problems that can't be solved with faster hardware, smarter software, and time.  In fact, I'd be interested in creating a reference implementation of a "projector" that takes the metadata we're defining here, a data-stream, and converts it for use in any venue.

In other words:  the receiver makes it right.   This is an old network software paradigm that has worked out quite well:  tell me what format you're sending me, give me the data, and I'll convert it into what I need.

(Interesting - now that I'm thinking this translator through, it's clear that we need a metadata format describing the theater, too.)

RSS

Fulldome Wikipedia Entry

Fulldome Video Discussion Group

Fulldome Database

Discussion Forum

Emerging Standards Effort in Immersive Audio (re-post) 2 Replies

Started by Ed Lantz. Last reply by Matthew Dougherty Aug 8, 2014.

GSCA-IMERSA Pre-Summit Workshop March 5th 2 Replies

Started by Dan. Last reply by Dan Jan 18, 2014.

Emerging Film Industry Standards to Watch: IMF, ACES and MXF 2 Replies

Started by Ed Lantz. Last reply by Ed Lantz Feb 14, 2013.

Dome Master Show File Format 1.0 - Sec.III - Audio Files 1 Reply

Started by IMERSA.org. Last reply by Ken Scott Jul 26, 2012.

IPS 2012 IMERSA Fulldome Standards Workshop

Started by IMERSA.org Jul 26, 2012.

Dome Master Show File Format 1.0 - Sec.VI - Digital Rights Management: Encryption, etc. 10 Replies

Started by IMERSA.org. Last reply by Ryan Wyatt Jul 16, 2012.

Dome Master Show File Format 1.0 - Sec. I - Metadata 6 Replies

Started by IMERSA.org. Last reply by IMERSA.org Jul 16, 2012.

Dome Master Show File Format 1.0 - Sec.II - Dome Master Working Specification 22 Replies

Started by IMERSA.org. Last reply by Jérémie Gerhardt Apr 26, 2012.

Dome Master Show File Format 1.0 - Sec.V - Program Distribution Medium 6 Replies

Started by IMERSA.org. Last reply by Jonathan Strawn Feb 6, 2012.

Latest Activity

Charles Treleaven posted blog posts
Saturday
Darcy Gerbarg posted a status
"Anyone using 3D capture video cameras for Domes?"
Wednesday
Darcy Gerbarg posted a status
"Anyone doing immersive AR or MR in Domes?"
Wednesday
suresh posted a blog post

prewarped

hi..plz let me know how to convert fisheye video to prewarped videos?See More
Aug 11

© 2019   Created by Dan.   Powered by

Badges  |  Report an Issue  |  Terms of Service