#304 Trackgen: object maps are read with wrong gamma
While creating a track with objects placed using the "object map" feature, I found that some objects where missing on the created track. After some testing, I found the problem was that trackgen was not finding some colors on the PNG object map. The only colors being recognized where FFFFFF, FFFF00, FF00FF, 00FFFF, FF0000, 00FF00 and 0000FF.
Although I'm no programmer at all, I had a look at tools/trackgen/objects.cpp and found that on the function GenerateObjects(), the call to load the PNG had a strange gamma value (2.0):
MapImage = GfImgReadPng(buf, &width, &height, 2.0, 0, 0);
Indeed, the images I can create with The Gimp always have a gamma of 2.2, so I suspected this was the problem. I changed the value, recompiled and everything seems to work fine now (that is, all the colors are found).
Perhaps not important for serious track developers who do all their work with a 3D package, but I like to create simple tracks and fill them with the object map feature, wich works great for that purpose (I only miss a way to align objects automatically to the track).
Happy new year to all, and sorry if I made some mistake: this is my first ever bug report.
--
Jaime
Sorry for responding to my own ticket, but I've just realized that elevation.cpp suffers from the same gamma problem, and as a result elevation maps are not properly "elevated" (I think it's worth reporting here instead opening a new ticket, as the solution is the same for both cases, but let me know if you prefer that I open a new one).
I was noticing some mismatch between the track and the terrain generated from my elevation files, but I was sure the max and min values were right, and then I figured out this was the gamma problem again... a look at elevation.cpp revealed that yes, GfImgReadPng was used again with a 2.0 gamma correction, while my generated elevation map was a png with a gamma of 2.2. Changing the code to use 2.2 resolved the problem, and now my terrain matches perfectly with the track.
Indeed, a search with regexxer showed no more occurrences on the whole 1.4.0 sources.
Regards,
--
Jaime
Thank you Jaime for the bug report.
It has driven me mad indeed when I could not use the object maps following the guides' advice.
I've checked what gamma is used often, and I've also found the 2.2 gamma value is more likely:
"... the average PC monitor has a built-in gamma of 2.2 when viewed in typical room lighting... ", http://morris-photographics.com/photoshop/articles/png-gamma.html
So I think this correction should happen - question is, where... Do we plan a new 1.4.X release or no? Should we issue a small patch on the homepage or only some kind of info? What can end-users of 1.4.X do about it?
Please fellow devs, share your thoughts.
r3240 and r3241 fix this issue for the 1.4.x branch, so SVN users can fetch a new 1.4 trackgen and use it from now.
Fixes in 2.0 will follow soon.
Related
Commit: [r3240]
Commit: [r3241]
r3242 fixes this issue for the trunk (2.0), too.
Meanwhile I've grepped for 'gamma' in the source and have found quite some places where gamma is set to 2.0 or 1.8 or even 1.7? I wonder if these gamma values are proved ones or ad hoc? But this is OT so I guess I'll open another ticket for that.
Related
Commit: [r3242]
although marked as fixed, i still get problems with this- see this thread: http://community.speed-dreams.org/viewtopic.php?f=5&t=720
i don't know how gimp estimates gamma, and saving gamma value on export does not solve the problem (at least for me, MiniJoe had more success).
Maybe PNG with its built-in gamma "correction" is not the best choice for maps, where exact rgb-values are most important?
I think sgi-format (.rgb) should work better, and SD already has a loader for them (?), but up to now, only png is allowed for maps.
Sorry for using this old ticket, should i rather post it as feature request..?
From:
http://www.libpng.org/pub/png/libpng-manual.txt
I am looking for a way to disable gamma correction for png's.
fixed with MiniJoes help:
remove speed-dreams\src\libs\tgfclient\guitexture.cpp Line 238 (the whole if-block). Don't know if it has any impact on the rest of SD as i did only compile trackgen, but for map processing, these lines cause more damage than use.
please fix this in the official version!!
any "correction" deforms rgb values, being lethal for object map processing.
as gamma interacts with a system-specific value, often defined rather accidentally, any value (2.2, 1.8 or whatever) can only work on a system using the exact same value.
the only way to make it work for an arbitrary system is not to do gamma "correction" at all (see above post).
i had fixed this in my 2.1 copy, but installing 2.2 took it back...
Diff:
I suggest to leace this fix after the release, because AFAICS it affects all png texture loading (at least in ssggraph), so might or might not cause problems with tracks / cars. Which seems a bigger problem than our trackgen sometimes not working.
I agree, I thought that a good course of action would be to "fix" it right after the release, so that we would have a full development cycle to discover any problems that it might cause. It will be difficult to test eveything.
Well, i don't think it would cause problems with pngs used as ordinary textures/graphics- indeed it would change the appearance of pngs with unusually low or high gamma, but the differences would be marginal, maybe not even visible to the eye (variance in graphics hardware and screen settings might be larger).
However, i totally understand your course not to risk other problems at this state... so i'll go back to my old trackgen temporarily :-)
I commited [r6393]. This adds an extra parameter to GfTexReadImageFromPNG(). This should allow gamma correction to be suppressed for only the trackgen uses of the function. All the png loading by ssggraph, etc should be unaffected. Please report any issues.
Related
Commit: [r6393]