All Macs prior to the release of OS X Snow Leopard (10.6) used the infamous display gamma of "1.8". More precisely, they applied an internal gamma correction of 1/1.45 (≈0.69, realized by a lookup table shown in this document: https://poynton.ca/PDFs/Rehabilitation_of_gamma.pdf on page 13; on the other hand, some sources suggest 1.39 instead, see https://www.w3.org/TR/WD-CSS2-971104/notes.html) before outputting the framebuffer to a display, which was supposed to more or less conform to the modern sRGB (or its predecessors, sRGB itself approximates the ~2.2 gamma, assumed as natural for CRT displays).
The emulators on Infinite Mac don't account for that - worse, they are not consistent with the color rendering:
This issue naturally doesn't apply to monochrome modes.
Mini vMac in 256-color Mac II mode doesn't do any gamma correction. Screenshots from that emulator require applying 1.45 gamma in post to brighten up the image to look "correct".
Basilisk II, SheepShaver and DingusPPC in indexed modes (up to "256 colors" or "256 grays") render colors correctly and screenshots look correct without any postprocessing - but below System 7.5 it's right only if switched into that mode. If it boots in the 256-color mode, the gamma correction is not applied and it requires a switch e.g. to "Millions" and back to get the gamma right. I think in some cases I got incorrect gamma as well, but all of the presets from the "Notable" page seem to look correct in 256-color mode.
None of the emulators in high and true-color modes ("Thousands" and "Millions" settings) do any gamma correction. Screenshots require applying 1.45 gamma in post to brighten up the image to look "correct".
I'm not entirely sure about the NeXT machines. From what I've heard, they use linear light values internally (gamma 1.0, so that would require ~2.2 correction in post to look correct) and indeed, if you apply 2.2 (some sources suggest 2.22, see https://www.w3.org/TR/WD-CSS2-971104/notes.html again) gamma correction to brighten up the image in post, the resulting images look more consistent with the available videos of NeXTSTEP/OPENSTEP running on original hardware (see e.g. https://www.youtube.com/watch?v=IoLrpMWMCFQ between 2:28 and 8:00, or https://www.youtube.com/watch?v=Bn7qIl59MAQ around 23:20 - there appears to be some discoloration in the video capture before that timestamp), or even on x86 virtual machines (see e.g. https://www.youtube.com/watch?v=gf5mUkZhYyI from 15:06).
I'm not sure how easy or hard that would be to implement, but I think it could be nice to have the proper gamma correction implemented in all modes, so that the emulated displays accurately represent what would be displayed by original hardware.
EDIT: Clarification: it's not super consistent between various sources whether gamma values are direct or inverse, e.g. whether 1.45 is "brighter" and 0.69 is "darker" or the other way round. I mostly used values of what you need to enter in GIMP's "Levels" filter to get the result right and added clarification about "brightening" to make it clear what's appropriate. If the number quoted does the opposite of the expected result for you, try the reciprocal, e.g. 0.69 instead of 1.45.
All Macs prior to the release of OS X Snow Leopard (10.6) used the infamous display gamma of "1.8". More precisely, they applied an internal gamma correction of 1/1.45 (≈0.69, realized by a lookup table shown in this document: https://poynton.ca/PDFs/Rehabilitation_of_gamma.pdf on page 13; on the other hand, some sources suggest 1.39 instead, see https://www.w3.org/TR/WD-CSS2-971104/notes.html) before outputting the framebuffer to a display, which was supposed to more or less conform to the modern sRGB (or its predecessors, sRGB itself approximates the ~2.2 gamma, assumed as natural for CRT displays).
The emulators on Infinite Mac don't account for that - worse, they are not consistent with the color rendering:
I'm not entirely sure about the NeXT machines. From what I've heard, they use linear light values internally (gamma 1.0, so that would require ~2.2 correction in post to look correct) and indeed, if you apply 2.2 (some sources suggest 2.22, see https://www.w3.org/TR/WD-CSS2-971104/notes.html again) gamma correction to brighten up the image in post, the resulting images look more consistent with the available videos of NeXTSTEP/OPENSTEP running on original hardware (see e.g. https://www.youtube.com/watch?v=IoLrpMWMCFQ between 2:28 and 8:00, or https://www.youtube.com/watch?v=Bn7qIl59MAQ around 23:20 - there appears to be some discoloration in the video capture before that timestamp), or even on x86 virtual machines (see e.g. https://www.youtube.com/watch?v=gf5mUkZhYyI from 15:06).
I'm not sure how easy or hard that would be to implement, but I think it could be nice to have the proper gamma correction implemented in all modes, so that the emulated displays accurately represent what would be displayed by original hardware.
EDIT: Clarification: it's not super consistent between various sources whether gamma values are direct or inverse, e.g. whether 1.45 is "brighter" and 0.69 is "darker" or the other way round. I mostly used values of what you need to enter in GIMP's "Levels" filter to get the result right and added clarification about "brightening" to make it clear what's appropriate. If the number quoted does the opposite of the expected result for you, try the reciprocal, e.g. 0.69 instead of 1.45.