pltovo / gimp-normalmap

Automatically exported from code.google.com/p/gimp-normalmap
Other
0 stars 0 forks source link

gimp-normalmap can create alpha value 0, then normals don't get saved #6

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a greyscale image that is also using the color black
2. Turn it into a normalmap with height in alpha
3. Save as TGA

What is the expected output? What do you see instead?
Expected output is a TGA file containing useful data even in the parts that 
have alpha value zero (as these still can have a normal vector). But, the TGA 
actually contains the RGB values (0, 0, 0) where A is 0.

What version of the product are you using? On what operating system?
GIMP 2.6.8
gimp-normalmap 1.2.2
Ubuntu

Please provide any additional information below.
The issue is most likely in GIMP saving the image, however, this decision done 
by GIMP makes sense in MOST cases, as pixels with alpha value 0 usually INDEED 
cannot contain any used data. Therefore, it would probably be best to avoid 
creation of zero alpha pixels inside gimp-normalmap, and use the alpha value 1 
(of 0 to 255) instead.

Original issue reported on code.google.com by divVer...@gmail.com on 20 Aug 2010 at 2:30

GoogleCodeExporter commented 8 years ago
Sorry for the extremely long delay in my reply.

It sounds like GIMP is multiplying the RGB values with alpha when saving a TGA 
image.  My advice would be to use PNG images.  Saving height to alpha is a good 
way to preserve the original grayscale height source with the normal map in a 
single image.  Altering this data is less than ideal in my opinion.

Original comment by ski...@gmail.com on 14 Jan 2011 at 8:52

GoogleCodeExporter commented 8 years ago
Nope, the saved TGAs still have separate and not premultiplied alpha. Also,
when the alpha value is as low as 1 (of 255), RGB is still fully preserved.

The issue persists when using the PNG format, even when enabling (anyway
enabled by default) the option "Save color values of transparent pixels". In
fact, I found out that the issue happens even before saving - in the channel
view, the pixels with zero alpha immediately appear black in the preview, and
when using Colors/Levels...  to map the alpha channel's range from 0..255 to
e.g. 128..255, one can clearly see that the color values already are lost the
very moment your plugin finished.

I agree to that. However, this combination of issues basically means that
gimp-normalmap is now incompatible with current GIMP. The only way to generate
a proper normalmap for the DarkPlaces engine (which also requires height in the
alpha channel for purposes of relief mapping) with GIMP has gotten much more
complex (as either the input height values have to be trimmed to 1..255, or the
output has to be merged with the heightmap using a separate tool) thanks to
this issue, although I do think it is an issue with GIMP.  However, from GIMP's
perspective, they have every right to not store alpha-zero gpixels in the
output.

Original comment by divVer...@gmail.com on 14 Jan 2011 at 10:15

GoogleCodeExporter commented 8 years ago
Ok.  Reopening the issue, and will find a workable solution.

Original comment by ski...@gmail.com on 14 Jan 2011 at 10:15