Skip to content

Conversation

@TallJimbo
Copy link
Contributor

This remaps NaN to ZBLANK whenever nullvalue is something (even if it's not NaN) and hence checking for nulls is enabled. Note that prior to this change, passing nullvalue=NaN had no effect because NaN != NaN, and hence any image that naturally had NaNs had to be modified in order to be saved with quantized compression, since otherwise the NaNs destroy everything.

This remaps NaN to ZBLANK whenever nullvalue is _something_ (even if
it's not NaN) and hence checking for nulls is enabled.  Note that
prior to this change, passing nullvalue=NaN had no effect because
NaN != NaN.
Copy link
Contributor

@beckermr beckermr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice patch @TallJimbo! Are we worried that at higher optimization levels the compiler might optimize away the comparisons in the if statements?

I wonder if maybe a more explicit check for nan using the fnan function would be better?

@TallJimbo
Copy link
Contributor Author

I'm not super familiar with the effects of higher optimization levels, but any level that could optimize that away sounds like one that is basically asserting that NaNs cannot exist.

@beckermr
Copy link
Contributor

Me neither. Hopefully they don't do that.

@c181gordon
Copy link
Collaborator

Hi @TallJimbo. Can you explain how you're actually getting NaNs to appear in the pixel arrays (fdata, rowpix, etc) inside quantize.c? In my tests, by the time imcompress.c functions call quantize.c, the NaNs are replaced with either of the FLOATNULLVALUE or DOUBLENULLVALUES placeholders defined in fitsio.h. Therefore I'm not seeing where quantize.c is actually trying to perform an "NaN == NaN" comparison.

@TallJimbo
Copy link
Contributor Author

It's possible I misdiagnosed this; I actually ended up working around this problem (by replacing my NaNs with -infs) and then went back and made this fix later, without testing that this fix removed the need for that workaround.

But one unusual thing I was doing in the tests that demonstrated the problem was passing a negative value to fits_set_quantize_level in order to set ZSCALE explicitly. I also tested passing a positive value in order to let CFITSIO determine ZSCALE from the image, but if it was only the negative-quantize-level tests that were failing (which I judged by whether ZBLANK appeared in the written file), I might not have noticed that distinction.

@c181gordon
Copy link
Collaborator

If no NaNs are detected, then it may not need to add a ZBLANK keyword. FWIW, in my test with NaNs and a negative quantization level (-4.0) using our 'fpack' utility, it still properly produces ZBLANK and successfully compresses the image. But if you want to send me a specific test case where the compression is failing, I'd be happy to try it out.

@TallJimbo
Copy link
Contributor Author

I'll try to reconstruct (and simplify) my failing test; might take me a little while.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants