Revisit ray4 file format

[hollasch]

Version should be bumped to 2.

What to do with bits-per-pixel? I think 12 is no longer needed. I think I might like the option of supporting floating-point values. 16-bit values might also be nice. Perhaps we need a type field (integer vs floating-point), and a size field. To start with, I think we should go with 24 / 48.

Aspect ratio is fine.

Replace start[3] and end[3] with resolution[3].

As a sketch:

magic : uint32          // Magic Number
version : uint8         // Image File Version Number
pixelType: uint8        // Pixel Type
aspect : uint16[3]      // Aspect Ratios [X,Y,Z]
resolution : uint32[3]  // Image Resolution [X,Y,Z]

(This new header is 24 bytes, same as the original size.)

The next file format version will be 0x02.

Legal pixel types are:

0x02 | unsigned integer, 0 to max value, RGB | 4 bits per color
0x03 | unsigned integer, 0 to max value, RGB | 8 bits per color
0x04 | unsigned integer, 0 to max value, RGB | 16 bits per color
0x14 | floating point, RGB | 16 bits per color
0x15 | floating point, RGB | 32 bits per color
0x16 | floating point, RGB | 64 bits per color
0x33 | unsigned integer, 0 to max value, monochrome | 8 bit
0x34 | unsigned integer, 0 to max value, monochrome | 16 bit
0x45 | floating point, monochrome | 32-bit
0x46 | floating point, monochrome | 64-bit

Likely just start with 0x02, 0x03. Add more as needed.

[neverhood311]

Any reason you didn't include RGBA? Also, why do you represent aspect ratios as integers? What if the resolution were 100101102? Then your aspect ratio is already encoded in the resolution.

On Thu, Oct 24, 2024, 3:46 AM Steve Hollasch @.***> wrote:

Version should be bumped to 2.

What to do with bits-per-pixel? I think 12 is no longer needed. I think I might like the option of supporting floating-point values. 16-bit values might also be nice. Perhaps we need a type field (integer vs floating-point), and a size field. To start with, I think we should go with 24 / 48.

Aspect ratio is fine.

Replace start[3] and end[3] with resolution[3].

As a sketch:

magic : uint32 // Magic Number version : uint8 // Image File Version Number pixelType: uint8 // Pixel Type aspect : uint16[3] // Aspect Ratios [X,Y,Z] resolution : uint32[3] // Image Resolution [X,Y,Z]

(This new header is 24 bytes, same as the original size.)

The next file format version will be 0x02.

Legal pixel types are:

0x02 | unsigned integer, 0 to max value, RGB | 4 bits per color 0x03 | unsigned integer, 0 to max value, RGB | 8 bits per color 0x04 | unsigned integer, 0 to max value, RGB | 16 bits per color 0x14 | floating point, RGB | 16 bits per color 0x15 | floating point, RGB | 32 bits per color 0x16 | floating point, RGB | 64 bits per color 0x33 | unsigned integer, 0 to max value, monochrome | 8 bit 0x34 | unsigned integer, 0 to max value, monochrome | 16 bit 0x45 | floating point, monochrome | 32-bit 0x46 | floating point, monochrome | 64-bit

Likely just start with 0x02, 0x03. Add more as needed.

— Reply to this email directly, view it on GitHub https://github.com/hollasch/ray4/issues/20, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDGYAVCJMBFXADMRP6C5ZDZ5CXW3AVCNFSM6AAAAABQQR3LDCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYTAOBZGA2DINY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[hollasch]

Any reason you didn't include RGBA?

I don't see any need. Since RGBA is used for image composition, I couldn't think of any need to generate new tools to compose 3D image cubes. One could proxy opacity through to 2D image slices, but again, I'm not sure what you'd use those for. I also haven't seen any ray tracers support alpha (that's typically something you do with rasterizing renderers), though I might be wrong. Are you planning on needing this somehow?

Also, why do you represent aspect ratios as integers? What if the resolution were 100×101×102? Then your aspect ratio is already encoded in the resolution.

Image resolution is independent of image aspect ratio. For example, a 100×101×102 resolution just tells me the count of increments in each dimension — it doesn't tell me anything about the spacing of these samples. That said, I'm considering dropping aspect ratio altogether and having these fixed at 1:1:1.

Generally it's nice to incorporate aspect ratio in anticipation of a particular (2D) display. So if I had a 4:3 aspect ratio in my display, I might want to bake that into my spatial sampling and thus into my image cube. However, that would also bake in the orientation of future image cube slices (like only taking slices orthogonal to the Z axis of the image cube). The more I think about this, the more marginal I think the utility would be. If you do have a non 1:1 aspect ratio display, I think I'd rather handle that in image cube slicing tools, rather than in the ray tracer.

[hollasch]

I'm getting more and more convinced of dropping aspect ratio in favor of a fixed 1:1:1 pixel spacing. Here's what I'm thinking now:

magic : uint32          // Magic Number
version : uint8         // Image File Version Number
pixelType : uint8       // Pixel Type
colorBitCount : uint16  // Pixel Color Size in Bits
resolution : uint32[3]  // Image Resolution [X,Y,Z]

Pixel Type

• 0x00 — RGB unsigned integers, 0 to max value
• 0x01 — RGB floating-point values, [0, 1]
• 0x02 — monochrome unsigned integer, 0 to max value
• 0x03 — monochrome floating-point value, [0, 1]

[neverhood311]

I'm not in that industry, but I know that at least Blender Cycles has the ability to render transparent backgrounds ( https://docs.blender.org/manual/en/latest/render/cycles/render_settings/film.html#transparent). You also need semi-transparent rendering for compositing shadows onto other footage. RGBA would give you some future resistance.

On Thu, Oct 24, 2024, 7:25 PM Steve Hollasch @.***> wrote:

I'm getting more and more convinced of dropping aspect ratio in favor of a fixed 1:1:1 pixel spacing. Here's what I'm thinking now:

magic : uint32 // Magic Number version : uint8 // Image File Version Number pixelType : uint8 // Pixel Type colorBitCount : uint16 // Pixel Color Size in Bits resolution : uint32[3] // Image Resolution [X,Y,Z]

Pixel Type

• 0x00 — RGB unsigned integers, 0 to max value
• 0x01 — RGB floating-point values, [0, 1]
• 0x02 — monochrome unsigned integer, 0 to max value
• 0x03 — monochrome floating-point value, [0, 1]

— Reply to this email directly, view it on GitHub https://github.com/hollasch/ray4/issues/20#issuecomment-2436565270, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDGYAS3GAFHACX7ASHCPO3Z5GFWHAVCNFSM6AAAAABQQR3LDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZWGU3DKMRXGA . You are receiving this because you commented.Message ID: @.***>

[hollasch]

Since image cubes are much more likely to have pixels representing unhit geometry ("the curse of dimensionality" works in our favor here), run-length-encoding would be frequently successful for image volumes. Come up with a scheme for pixel, scanline, and scanplane RLE.