-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Grays wrapping signed FixedPointNumbers #41
Comments
Here's a shorter example julia> using ImageShow, FixedPointNumbers, Colors
julia> rand(Gray{Q0f31}, 100, 100)
All errors:
===========================================
ArgumentError: Q0f31 is a 32-bit type representing 4294967296 values from -1.0 to 1.0; cannot represent 1
===========================================
ArgumentError: Q0f31 is a 32-bit type representing 4294967296 values from -1.0 to 1.0; cannot represent 1
===========================================
FileIO.MimeWriter writer error: neither save nor fileio_save is defined
due to MethodError(FileIO.MimeWriter.var"#save##kw"(), ((mapi = ImageShow.var"#8#10"(),), FileIO.MimeWriter.save, FileIO.Stream{FileIO.DataFormat{:PNG}, IOContext{Base64.Base64EncodePipe}, Nothing}(IOContext(Base64.Base64EncodePipe(IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true, append=false, size=0, maxsize=Inf, ptr=1, mark=-1), Base64.Buffer(UInt8[0xf0, 0xee, 0x9c, 0x80, 0x57 |
What should be the expected behavior here? |
What makes the most sense to me is to remap negatives as one color and positives as another say (green and magenta) to preserve the sign information. Neither clamping nor linear contrast adjustment does that. Why else would the user be using a signed FixedPointNumber if they didn't want the signed info preserved? So have the type range: julia> Gray(typemin(Q0f31))
Gray{Q0f31}(-1.0Q0f31)
julia> Gray(typemax(Q0f31))
Gray{Q0f31}(0.9999999995Q0f31) map linearly to green and magenta, respectively. With zero equal to black. |
I'm not sure if this should be the default behavior because people may have different tastes. We might apply Would you mind uploading one or two images to play with? |
That's fair, but then why would the user be using a signed FixedPointNumber if we're just going to throw away the negatives? An easy example is julia> rand(Gray{Q0f31}, 100, 100) |
Okay, I see your point. There's nothing special about FixedPointNumbers here; if we want to preserve the out-of-range value information, then we should treat it in a type-agnostic way. This issue should be fixed in two steps:
The way you proposed for Gray sounds good to me, now I'm more concerned with RGB values.
I'm saying that overly using the type information to change the behavior could sometimes be problematic. Just a quote from tim:
|
I ran into this issue again. I think it's less important exactly how we display the image, we can pick one thing and stick with it. The current behavior is still the following, which is quite annoying to deal with in an interactive environment like IJulia:
I'm fine with simply clamping to positive values for display as long as we throw a warning that we're modifying the data for display. That should work for both RGB and Gray values. |
Currently ImageShow breaks when trying to display images with signed FixedPointNumbers, e.g.
Q0f31
, etcexample.tif
is from tlnagy/TiffImages.jl#56 (comment)It would super nice to display these sorts of images properly, i.e. with one color for negative numbers and another for positive or even reinterpreted as normed FixedPointNumbers. The former is definitely preferable, but the current behavior isn't nice for the end user.
The text was updated successfully, but these errors were encountered: