I didn't answer to the question on negative zero, so here are some clues. When using floating point, in general is a bad idea to check for equality. The internal representation of floating point numbers makes exact equality problematic. Just as an example 0.1 is periodic in binary representation, adding 0.1 ten times gives a result which is close but not exactly 1.
A good way to check for equality is to take the difference of both numbers, the expected and the obtained, to be less than an epsilon. This epsilon is often quite small. Something like 0.00001 in 32 bit floats. The obtained number may be before or after expected number. We prefer to use something called the "bankers rounding" that distributes the error sometimes after and sometimes before. Choosing always the value after may have perverse side effects on certain fields, financials for example. So, since the expected number is 0, and we use float, it makes sense to get sometimes a number before. An this is a negative epsilon. This means nothing but a very close number. Hope it makes sense Regards Marti Quoting marti.ma...@littlecms.com: > Hi Elle, > > Sorry, with the profiles you sent and transicc from lcms2-2.6, this > does not happen. I got the expected values. > Please check the version of lcms2 you are using. > > BTW, -c0 is not needed in lcms2 and may cause problems. This may be > the source of the issue in versions previous to 2.6 > > M:\lcms2-2.6\bin>transicc -c0 -t1 -w -o sRGB-V2-g10.icc -i sRGB-V4-g20.icc > LittleCMS ColorSpace conversion calculator - 4.2 [LittleCMS 2.06] > > Enter values, 'q' to quit > R? 255 > G? 0 > B? 0 > > R=255.0000 G=0.0000 B=-0.0000 > > Enter values, 'q' to quit > R? 255 > G? 255 > B? 0 > > R=255.0000 G=255.0000 B=0.0000 > > Enter values, 'q' to quit > > > Regards > Marti > > Quoting Elle Stone <ellest...@ninedegreesbelow.com>: > >> Transicc and also tificc both produce oddly wrong results when >> converting near-zero and zero RGB channel values from one RGB matrix >> profile to a second RGB matrix profile with a different TRC but the same >> colorants (as per converting a linear gamma sRGB image to regular sRGB). >> >> Below are some transicc examples. The profile names indicate the profile >> spec version and the TRC. All the profiles were made using LCMS2 and >> have identical colorants and chad/white point. >> >> First case: Both profiles have a true gamma TRC (V4 vs V2 makes no >> difference): >> >> transicc -c0 -t1 -w -o sRGB-V2-g10.icc -i sRGB-V4-g20.icc >> >> 255 255 0 >> R=255.0000 G=255.0000 B=0.0134 (the B channel should be zero) >> >> 255 0 0 >> R=255.0000 G=0.0282 B=0.0000 (the G channel should be zero) >> >> 255 0 255 >> R=255.0000 G=0.0331 B=255.0000 (the G channel should be zero) >> >> 255 0.001 0.001 >> R=255.0000 G=0.5037 B=0.5051 (G and B should be equal to each other) >> >> >> Going the other way produces negative RGB channel values: >> >> transicc -c0 -t1 -w -i sRGB-V4-g20.icc -o sRGB-V2-g10.icc >> >> 255 0 0 >> R=255.0000 G=0.0000 B=-0.0000 (negative B channel) >> >> 255 0.001 0.001 >> R=255.0000 G=0.0000 B=-0.0000 (negative B channel) >> >> 70000 0.001 0.001 >> R=19215684.3750 G=-0.3511 B=0.0270 (the G and B channel values should be >> equal and positive) >> >> >> Second case: The destination profile has the V4 sRGB parametric TRC: >> >> transicc -c0 -t1 -w -i sRGB-V4-g10.icc -o sRGB-V4-srgbtrc.icc >> >> 0.0001 255 0.0001 >> R=0.0015 G=255.0000 B=0.0013 (R and G channels should be equal) >> >> 255 0 0 >> R=255.0000 G=0.0000 B=-0.0000 (negative B) >> >> 0 255 0 >> R=-0.0002 G=255.0000 B=-0.0000 (negative B) >> >> 0 0 255 >> R=-0.0001 G=0.0000 B=255.0000 (negative R) >> >> >> When using GIMP 2.9 from git (which uses LCMS2) to do the same profile >> conversions, it turns out that the "zero" and "-zero" channel values are >> actually slightly positive and slightly negative at floating point >> precision. At 16- and 32-bit integer precision the "zero" values are >> slightly positive. >> >> If the destination profile has the "V4-when-saved-as-V2" 4096-point sRGB >> TRC, then there are no negative channel values, and the near-zero >> channel values are always equal to each other if the channel values are >> equal to each other in the source color space. However, the resulting >> RGB channel values in the destination color space are quantized, which >> means information is lost. >> >> Why the odd conversion results for zero and near zero channel values? Is >> there a workaround? Or perhaps I'm using the wrong LCMS ICC profile >> conversion parameters? >> >> Best regards, >> Elle >> >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> Lcms-user mailing list >> Lcms-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/lcms-user > > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Lcms-user mailing list > Lcms-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lcms-user ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
