Menu
▾
▴
Re: [OSSIM] Adding alpha channel
|
From: Peter B. <pet...@sp...> - 2010-10-01 12:03:20
|
Same bit depth as the input would be ideal but I understand it's a bit more work. I suggested to Dave that we should stuff the alpha in a "band" and add an attribute to indicate whether the band is alpha or not. Normalized floats is a viable alternative. Peter ________________________________________ From: Garrett Potts [po...@cf...] Sent: Friday, October 01, 2010 7:07 AM To: Peter Borissow Cc: David Burken; oss...@li... Subject: Re: [OSSIM] Adding alpha channel Hello Peter: I have have seen this on many occasions as well and I think we are in complete agreement on the need for an alpha. What keeps going through my mind is what bit depth should we represent the alpha? There are several choices: - Save space and always use 0-255 unsigned char for alpha. If higher precision is required then this is a problem. - use normalized floats. Always between 0 and 1. Increases size by 4 bytes per pixel but allows for smoother alpha transitions and less aliasing on algorithms that use it for any bit depths like feathering. - Same bit depth as the input. Much more work for if there are scalar remaps the alpha must also get remapped. I would like to push for the first or the second technique. The most flexible is the second. I agree also about the bandaid. I think if an alpha is added we can decouple other algorithms very easily for example, pixel flip could just set the alpha value and also seam line generation for adaptive feathering would be easier. Take care Garrett On Oct 1, 2010, at 5:38 AM, Peter Borissow wrote: > Here's an image to illustrate my point. I took a standard JPEG and converted it to a PNG using orthoigen (--writer-prop add_alpha_channel=true). All the black pixels (0,0,0 in RGB) are flipped to NULL. You'll see the null pixels highlighted in red. > > JPEGs of course, have no NULL values. There is no alpha channel. Flipping the black pixels to null in this case is wrong. You'll see the same bug/feature with any input image with black pixels (NITF, TIF, SID, etc). > > As a workaround, we are contemplating a variety of options including a mask filter to substitute null pixels that fall within an image footprint with black pixels. Of course, that's just a band-aid in my opinion. > > Peter > > > ________________________________________ > From: David Burken [db...@co...] > Sent: Thursday, September 30, 2010 9:58 PM > To: oss...@li... > Subject: Re: [OSSIM] Adding alpha channel > > Hi Peter, > > Yeah that's by design in ossimImageData::computeAlphaChannel any null > will set the alpha pix to 0. So if null is 0 then it's doing what it > was designed to. The problem is handling data sets that don't have a > null concept, i.e. treat 0 as a valid pixel. > > Talk to you later, > Dave > > On 9/30/2010 5:39 PM, Peter Borissow wrote: >> Hey Dave- >> Thanks for starting the thread. The inability to properly handle the alpha channel is a major bug in my opinion. We recently built a WMS using OSSIM and support transparent PNGs as one of the output formats. With PNG, black pixels are *ALL* being flipped to null. It's pretty bad, especially if you're looking at SAR or map with black text. Looking forward to working with you guys to get this fixed! >> >> Take Care, >> Peter >> >> >> >> -----Original Message----- >> From: David R. Burken [mailto:dav...@sp...] >> Sent: Thursday, September 30, 2010 8:50 AM >> To: oss...@li... >> Subject: [OSSIM] Adding alpha channel >> >> Hi everyone, >> >> Just wanted to start a discussion. We'd like to look into carrying an alpha channel trough the chain for data sets that have them. This is a pretty big change to the core. I added and alpha channel attribute to the ossimImageData(tile) a while back with a compute alpha method. Currently this is only used for the jp2 writer. Some thoughts on this: >> >> 1) The alpha channel is currently uint8. Perhaps this should be dynamic? So you could make it float or whatever. Binary alpha maybe (8 pixels per byte)? >> >> 2) All filters that check for nulls would have to be examined/possibly touched, changed to go through ossimImageData::isNull method. >> >> 3) I see mosaicing issues between (example): >> >> 3a) data that has and alpha and uses 0 as a valid pixel >> 3b) data that has no alpha and uses 0 as null >> 3c) data that has no alpha and use 0 as valid pixel (no null) >> >> Note I'm using "0" here but understand this could be something else for signed data. >> >> 4) I think we should support both with and without alpha. >> >> Another issue we're having (kind of related) is with data that has no null concept, where 0 is used as valid pixel. This is an age old problem. Currently thinking of using pixel flipper; however, there's issues with that detecting "has a null concept" or "0 is valid pixel". Not sure of a good solution for this... One potential solution is scan the image to see if there is a null in between valid pixes; is so, get out and turn on pixel flipping. >> >> For those who don't know we have two filters ossimPixelFlipper and ossimNullPixelFlip which were written to fix things like the above. For instance you have data where the null fill is 255 which for us is usually white. >> >> That's all I can think of now. >> >> Take care, >> Dave >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> www.ossim.org >> Ossim-developer mailing list >> Oss...@li... >> https://lists.sourceforge.net/lists/listinfo/ossim-developer >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> www.ossim.org >> Ossim-developer mailing list >> Oss...@li... >> https://lists.sourceforge.net/lists/listinfo/ossim-developer >> > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > www.ossim.org > Ossim-developer mailing list > Oss...@li... > https://lists.sourceforge.net/lists/listinfo/ossim-developer > <Bad Pixels.jpg>------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > www.ossim.org > Ossim-developer mailing list > Oss...@li... > https://lists.sourceforge.net/lists/listinfo/ossim-developer |