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

image/color: when color.ModelFunc.Convert,it seems no need pre rendering #5854

Closed
gopherbot opened this issue Jul 10, 2013 · 9 comments
Closed
Milestone

Comments

@gopherbot
Copy link

by augustheart:

I found these code at "func nrgbaModel(c Color) Color" and "func
nrgba64Model(c Color) Color" in "image/color"
"
    // Since Color.RGBA returns a alpha-premultiplied color, we should have r <= a && g <= a && b <= a.
    r = (r * 0xffff) / a
    g = (g * 0xffff) / a
    b = (b * 0xffff) / a
"
It seems no need for precess a image.And when we process a paletted png,these code will
distory the palette.
example:
    f,_ := os.Open("sample.png")
    defer f.Close()
    img,_ := png.Decode(f)
    out,_ := os.Create("result.png")
    defer out.Close()
    png.Encode(out,img)
If the sample.png is a paletted png with alpha,these code will generate a different pLTE
@robpike
Copy link
Contributor

robpike commented Jul 26, 2013

Comment 1:

Not sure I understand the issue. Assigning to Nigel to test it out.

Labels changed: added priority-soon, packagebug, removed priority-triage.

Owner changed to @nigeltao.

Status changed to Accepted.

@nigeltao
Copy link
Contributor

Comment 2:

I also don't fully understand the issue. Do you think there's a problem based solely on
looking at the code, or do you have an actual PNG image file where you've ended up with
a different palette? The image/png reader code generates RGBA palette colors if they're
opaque, otherwise NRGBA colors.
For fully opaque colors, the transformation between RGBA and NRGBA should be lossless;
the program below does not print anything. For transparent colors, there is no
transformation, as we're always in NRGBA.
--------
package main
import (
    "fmt"
    "image/color"
)
func main() {
    for r := 0; r < 256; r++ {
        c0 := color.RGBA{uint8(r), 0, 0, 0xff}
        c1 := color.NRGBAModel.Convert(c0).(color.NRGBA)
        c2 := color.RGBAModel.Convert(c1).(color.RGBA)
        if c0.R != c1.R || c0.R != c2.R {
            fmt.Printf("%02x\n", c0.R)
        }
    }
    for r := 0; r < 65536; r++ {
        c0 := color.RGBA64{uint16(r), 0, 0, 0xffff}
        c1 := color.NRGBA64Model.Convert(c0).(color.NRGBA64)
        c2 := color.RGBA64Model.Convert(c1).(color.RGBA64)
        if c0.R != c1.R || c0.R != c2.R {
            fmt.Printf("%04x\n", c0.R)
        }
    }
}
--------

Status changed to WaitingForReply.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 3:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 4:

Labels changed: added feature.

@gopherbot
Copy link
Author

Comment 5 by augustheart:

Sorry left for days.I had replied a mail with some sample file.

@nigeltao
Copy link
Contributor

nigeltao commented Aug 7, 2013

Comment 6:

Who did you send that mail to? I don't think that I got it.
Can you point your browser to https://golang.org/issue/5854 and
upload that sample to the issue page instead?

@gopherbot
Copy link
Author

Comment 7 by augustheart:

I replied from my gmail to the account named go@googlecode.com.This is my first time use
googlecode,I thought it could to the correct address.
there are "sample.png" and "result.png". you can find the different form "different.jpg"
easily.
By the way,sample.png is a illeag file,in my country,it not a big matter,but maybe you
must delete it...(becouse I can't find another fit image in my harddisk,after all we use
RGBA PNG or jpeg in daily life,and these format can't trigger this bug)

Attachments:

  1. sample.zip (11950 bytes)
  2. result.zip (12568 bytes)
  3. different.jpg (127311 bytes)

@gopherbot
Copy link
Author

Comment 8 by augustheart:

And...as I submitted this issue,I thought I find the reason.but now I not sure
it.becouse there are only last two palette different.

@nigeltao
Copy link
Contributor

Comment 9:

Both sample.png and result.png have the same PLTE chunk. The difference is that the tRNS
chunk is 256 bytes long for sample.png and 254 bytes long for result.png. The final two
tRNS bytes for sample.png are 0xff and 0xff.
The PNG spec at http://www.w3.org/TR/PNG/#11tRNS says that "The tRNS chunk shall not
contain more alpha values than there are palette entries, but a tRNS chunk may contain
fewer values than there are palette entries. In this case, the alpha value for all
remaining palette entries is assumed to be 255."
It seems to me that Go's image/png package is writing a valid (shorter) tRNS chunk but
your viewing program (I don't know what it is called but it is what's seen in
different.jpg) is not following the PNG specification. The bug lies in that program, not
in Go.

Status changed to WontFix.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants