En sjælden gang bliver "mine" jpg-billeder rødlige (Andy Warhol look alike)
Jeg har kogt det ned til følgende linier kode: BufferedImage imageio = ImageIO.read(new File("billede_ind.jpg")); ImageIO.write(imageio, "jpg", new File("billede_ud.jpg"));
Nogle har foreslået at de billeder, der bliver rødlige er ARGB, mens de normale er RGB. Men, jeg har checket imageio.getColorModel() som er den samme, både på de billeder, der forbliver normale, og de billeder, der bliver røde: ColorModel: #pixelBits = 24 numComponents = 3 color space = java.awt.color.ICC_ColorSpace@6539841e transparency = 1 has alpha = false isAlphaPre = false
Jeg antager, at det er læse-operationen, der er problemet. Hvis det var skrive-operationen, så ville det vel gå ud over alle billederne.
Jeg har forsøgt at dykke ned i Javas jpg-billedformater, men jeg kan ikke finde nogle gode beskrivelser.
Er der nogen, der kan fortælle mig, hvad der sker?
Jeg bruger Java1.7 Og nej, lad nu være med at foreslå en nyere version. Det er ikke en option.
"Er problemet fast ved visse billeder, således at et bestemt billede altid bliver røde, mens de fleste billeder aldrig bliver røde?" ja!
"Bliver det også rødt når man åbner og gemmer i et andet program f.eks. Paint?" Nej!
Jeg har nu sat et rødt billede som profilbillede. Når du har kommenteret på dette indlæg, vil jeg uploade det oprindelige billede som profilbillede. (Det er min workaround på ikke at kunne uploade billeder.)
Ja, jeg har set beskrivelsen i stackoverflow. Det ser ud til at være den samme effekt, men når jeg bruger billede, som er vist i stackoverflow-linket, så har jeg ikke problemer med at læse/skrive det.
så du den tilføjelsen? It was the Alpha value. Fixed by :
BufferedImage image = new BufferedImage(iw,ih,BufferedImage.TYPE_INT_RGB); //RGB, jpeg hasnt got alpha, ints have been converted as if they contain red first, but its alpha(the first bytes, these ints are interpreted bitwise i think) (argb), so it became more red.
Derudover er ColorModel: #pixelBits = 24 numComponents = 3 color space = java.awt.color.ICC_ColorSpace@3d83b5a1 transparency = 1 has alpha = false isAlphaPre = false Hvis alpha er benyttet i det oprindelige billede, så havde jeg forventet noget ala: ColorModel: #pixelBits = 32 numComponents = 4 color space = java.awt.color.ICC_ColorSpace@3d83b5a1 transparency = 1 has alpha = true isAlphaPre = true.
Ja, mit webhotel (Levonline.com) er teknisk set temmeligt langt bagud, når det kommer til Java, og deres administration er håbløs. MEN deres teknikkere er første klasses. De svarer meget hurtigt og kvalificeret, når jeg har spørgsmål. Derudover er jeg også godt tilfreds med deres båndbredde. Mit site har temmelig meget trafik.
Jeg har kikket på pixel (0,0) på det indlæste billede. Den har farverne: a:255 r:229 g:133 b:126 Det passer jo fint med, at billedet er rødt. Så kunne man jo forledes til at tro, at det havde noget med Alpha-værdien at gøre. MEN, Men, men, Alpha-værdierne er også 255 på de billeder, der bliver læst og skrevet igen korrekt. SUK...
Måske løsningen er at benytte en anden indlæsningsmetode end ImageIO.
public class T3 { public static void main(String[] args) throws Exception { ImagePlus img = new ImagePlus("before.jpg"); BufferedImage buf = img.getBufferedImage(); ImageIO.write(buf, "jpg", new File("after.jpg")); } }
Det gode ved det er at du faar et BufferedImage d.v.s. at det ikke skulle paavirke den kode ret meget.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
