Open
Bug 687062
Opened 13 years ago
Updated 2 years ago
Missing alpha channel when loading RGBA BMP image into a WebGL texture.
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
NEW
People
(Reporter: zlgong1984, Unassigned)
References
Details
Attachments
(2 files, 1 obsolete file)
525.65 KB,
application/octet-stream
|
Details | |
8.61 KB,
patch
|
joe
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110908135051
Steps to reproduce:
I want to load a RGBA BMP image into a WebGL texture.
The texture is for a tree model. The RGB channel of the texture stored color map and the alpha channel of which stored the opacity map of the tree leaves.
Actual results:
Everything works fine in chrome, but in firefox, I found that only RGB parts of the image were loaded into the texture, however, the alpha channel is always 1.0 no
matter what the value is in the image.
Expected results:
The alpha value of the image should enable WebGL performs alpha testing when rendering the tree model.
Comment 1•13 years ago
|
||
Brian tells me that it's worth trying Firefox 9 (Nightly) as this might have changed.
Also notice that the BMP file format is obsolete and if you have a choice, it's better to use PNG.
Comment 2•13 years ago
|
||
I confirm that the texture is working fine in Firefox 9 :-)
Notice that to allow using local files as textures you need to go to about:config and set security.fileuri.strict_origin_policy to false. Only do this in a test profile, as this is a security vulnerability.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 3•13 years ago
|
||
oops. No, not fixed in Firefox 9, sorry. The texture is indeed rendered as fully opaque in Firefox 9 while it is transparent in Chrome 13.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---
Comment 4•13 years ago
|
||
Support was actually added in Firefox 9 for transparent bitmaps, but we only enable it currently for bitmaps loaded inside an icon file. I did this only to keep everything the same as it used to be and not cause new regressions. This shouldn't be too hard to enable.
I want to test it, and verify if we should only enable it for certain bitmap headers, but all we should have to do is default mUseAlphaData to true in the BMP decoder.
http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/decoders/nsBMPDecoder.cpp#76
Updated•13 years ago
|
Assignee: nobody → netzen
Reporter | ||
Comment 5•13 years ago
|
||
We are working on Oak3D project which is an free WebGL based javascript framwork.
So we can not put certain limitation on what kind of image the developers should use, indeed, this often depends on artist who creating the art asset.
And opacity map I think is often used in real-time rendering when simulate plants,railings and so on, so I hope this can be fixed in the near future:)
Thank you very much!
Updated•13 years ago
|
Status: REOPENED → ASSIGNED
Comment 6•13 years ago
|
||
For a 40 byte file headers, the BMP spec says that the 4th byte should be reserved and always 0.
The BMP file format does not specify what should happen when this value is not 0.
The ICO file format though specifies that the 4th byte can be used for transparency (if not all 0) when a BMP is stored.
Programs that use the 4th byte for alpha data: Google Chrome, and GIMP
Programs that do not use the 4th byte: Firefox all versions, IE, Windows, Photoshop
I don't see any harm in supporting this for BMP files though.
Supporting it is only 1 line of code because the code is already there for handling of ICO files that use the transparency byte for each quad.
Comment 7•13 years ago
|
||
By the way, BMPs with BITMAPV3INFOHEADER and above support transparency properly but I don't know of any program that generate them. The bitmap in this bug report falls into the case of a 40 byte file header which is for BITMAPINFOHEADER and is using the 4th byte as alpha (as if it were a BMP inside of an ICO).
Comment 8•13 years ago
|
||
Confirmed that the WebGL texture works now in the demo.
We support RGBA BMPs the same as Google Chrome and GIMP with this patch.
We did not support RGBA BMPs ever before this patch though.
Attachment #560827 -
Flags: review?(joe)
Updated•13 years ago
|
Component: General → Canvas: WebGL
Product: Firefox → Core
QA Contact: general → canvas.webgl
Updated•13 years ago
|
Component: Canvas: WebGL → ImageLib
QA Contact: canvas.webgl → imagelib
Comment 9•13 years ago
|
||
Comment on attachment 560827 [details] [diff] [review]
Patch for adding RGBA BMP support
Review of attachment 560827 [details] [diff] [review]:
-----------------------------------------------------------------
I think you should just remove mUseAlphaData, since now it's only ever set to true.
Attachment #560827 -
Flags: review?(joe) → review-
Comment 10•13 years ago
|
||
ok will do.
Comment 11•13 years ago
|
||
Attachment #560827 -
Attachment is obsolete: true
Attachment #561112 -
Flags: review?(joe)
Updated•13 years ago
|
Attachment #561112 -
Flags: review?(joe) → review+
Comment 12•13 years ago
|
||
Comment 13•12 years ago
|
||
What happened after pushing to try?
Comment 14•12 years ago
|
||
Sorry not sure what happened on this one, I think this patch should be redone/updated though after bug 722555 lands.
Assignee: netzen → nobody
Comment 15•11 years ago
|
||
Bug 722555 was landed far back. Is this bug forgotten again?
Flags: needinfo?(netzen)
Comment 16•11 years ago
|
||
Note this is not a regression from bug 722555.
It is not forgotten it's just was never a priority for me in comparison to other things.
If you want this fixed please try to find another owner.
Flags: needinfo?(netzen)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•