RGBELoader magic header check

[Usnul]

Describe the bug

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

three.js/examples/jsm/loaders/RGBELoader.js

Lines 149 to 154 in 1e161ea

	/* 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:

Loader doesn't recognize the magic token though.

Here's what line contents are when printed to console:

Now the curious part here is if you try to copy that and check the match again:

All looks good, however, if you try it on the line directly, you will see this:

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

A bit extra:

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]

[gkjohnson]

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.

[mrdoob]

@Usnul do you mind testing that fix?

[Usnul]

Yes, this works.