Skip to content
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

Float64->UInt8 unexpectedly get affected in v0.7.0 #164

Closed
johnnychen94 opened this issue Jan 11, 2020 · 6 comments
Closed

Float64->UInt8 unexpectedly get affected in v0.7.0 #164

johnnychen94 opened this issue Jan 11, 2020 · 6 comments

Comments

@johnnychen94
Copy link
Collaborator

johnnychen94 commented Jan 11, 2020

Any ideas of how the results are changed upgrading from v0.6.1 to v0.7.0? I'll check that later if nobody does... (Catching a cold now and my mind goes blank...)

Here is the minimal codes I can provide so far:

using ImageCore, TestImages, SHA
img = RGB{Float64}.(testimage("lena_color_256"))
img_str = bytes2hex(sha256(reinterpret(UInt8, vec(rawview(channelview(img))))))
# 0.6.1
24d5be33008cdfbc38845b2e5929b90db693ac203f9bf0fea76e39d45746f798
# 0.7.0
39869ae780dc1242d3e223a83b8ddadd868c1503b65de44dc5e5e5b2022da9cd

c.f. JuliaTesting/ReferenceTests.jl#46

@kimikage
Copy link
Collaborator

kimikage commented Jan 11, 2020

I'm checking just to be sure, but this is not the difference on Normed-->Float64 conversions, right?

julia> for x=0:255; x*(1/255) == x/255 || @show x; end
x = 33
x = 37
x = 41
x = 45
x = 49
x = 53
x = 57
x = 61
x = 66
x = 74
x = 82
x = 90
x = 98
x = 106
x = 114
x = 122
x = 132
x = 148
x = 164
x = 180
x = 196
x = 212
x = 228
x = 244

@johnnychen94
Copy link
Collaborator Author

johnnychen94 commented Jan 12, 2020

this is not the difference on Normed-->Float64 conversions, right?

You got it! I really should have checked that yesterday. The saved JLD files of img here are different in the two versions.

julia> euclidean(img06, img07)
1.0021492566079894e-14

Should users be worried about this? Probably no I guess.

@kimikage
Copy link
Collaborator

Should users be worried about this?

I think it depends on the usage or purpose. For example, it can be problematic in the tamper detection or steganography. However, I don't think it is necessary to reduce accuracy for the compatibility. In any case, ReferenceTests.jl is working correctly.

@johnnychen94
Copy link
Collaborator Author

Could you point me to the PR where the behavior of N0f8->Float64 is changed? I'm still curious about that.

@kimikage
Copy link
Collaborator

PR #138 (and PR #145)

function Base.Float64(x::Normed{UInt32,f}) where f
f64 = Float64(x.i)
f == 1 && return f64
f == 2 && return (f64 * 0x040001p0) * 0x15555000015555p-72
f == 3 && return (f64 * 0x108421p0) * 0x11b6db76924929p-75
f == 4 && return (f64 * 0x010101p0) * 0x11000011000011p-72
f == 5 && return (f64 * 0x108421p0) * 0x04000002000001p-75
f == 6 && return (f64 * 0x09dfb1p0) * 0x1a56b8e38e6d91p-78
f == 7 && return (f64 * 0x000899p0) * 0x0f01480001e029p-70
f == 8 && return (f64 * 0x0a5a5bp0) * 0x18d300000018d3p-80

@johnnychen94
Copy link
Collaborator Author

johnnychen94 commented Jan 12, 2020

These lines are spells to me but I trust you that's making things better 😃 . I'm closing this now.

johnnychen94 added a commit to JuliaTesting/ReferenceTests.jl that referenced this issue Jan 12, 2020
The accuracy of N0f8->Float64 conversion is improved in
FixedPointNumbers v0.7

cf: JuliaMath/FixedPointNumbers.jl#164
johnnychen94 added a commit to JuliaTesting/ReferenceTests.jl that referenced this issue Jan 12, 2020
The accuracy of N0f8->Float64 conversion is improved in
FixedPointNumbers v0.7

cf: JuliaMath/FixedPointNumbers.jl#164
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

No branches or pull requests

2 participants