RGBELoader magic header check

Describe the bug

RGBELoader checks for magic token at the start of the file:

/* if you want to require the magic token then uncomment the next line */
if ( ! ( match = line.match( magic_token_re ) ) ) {
return rgbe_error( rgbe_format_error, ‘bad initial token’ );
}

I have a file that has the said header:
image
Loader doesn’t recognize the magic token though.

Here’s what line contents are when printed to console:
image

Now the curious part here is if you try to copy that and check the match again:
image
All looks good, however, if you try it on the line directly, you will see this:
image

The problem is that there’s a 
 at the end (carriage return):
image
image

A bit extra:
image
It looks like both 13 and 10 are interpreted as NEW_LINE char by the ingestion function fget

To Reproduce

  • can’t share the file at this moment

Code


Live example

  • can’t share the file at this moment

Expected behavior

I’m not sure, I believe this should be treated as a valid header. This problem did not occur when using r107, so it looks like a regression bug. But perhaps someone more familiar with the RGBE spec can clarify.

Screenshots

see above

Platform:

  • Device: [Desktop]
  • OS: [Windows]
  • Browser: [Chrome]
  • Three.js version: [r??? – yes, 123]

Author: Fantashit

1 thought on “RGBELoader magic header check

  1. I can’t find anything online that states the bytes that come after #?RADIANCE should be restricted. This reference on the spec seems to indicate that it’s enough for the first bytes be #?RADIANCE and that a newline does not need to follow.

    Changing magic_token_re from this

    magic_token_re = /^#\?(\S+)$/

    to this

    magic_token_re = /^#\?(\S+)/

    seems like a fix.

Comments are closed.