Right. But [0,1] has 127 exponent values (not considering subnormals), not just 1. So what you write is correct, but a bit misleading. In fact, half of all the float values are in the [0, 1] range…
EDIT: half of the positive float values (obviously)
Correct. But this has no bearing on (relative) precision/quantization, i.e. you can’t say the [0, 1]) range is “more precise” because these values are not uniformly distributed in this range. The precision is always approx. 2^-24 relative to the particular value you’re interested in.
This would be like saying [0, 0.5) is “more precise” because it has e.g. 3 times the representable values in it compared to the [0.5, 1) range. What does it say about your [0, 1) range then?
What I’m saying (and I’m pretty sure you know all this) is that floats are useful (among other things) exactly because their density is relative to the magnitude, i.e. you have more values where it matters the most (when talking about image processing operations, which is our context here). In other words, the fact that 10^9 == 10^9+1 in float in inconsequential, because the two values are nearly the same in terms of magnitude, whereas the closer you get to zero (in absolute value), the more digits you want, roughly speaking. That’s what “floating” means. If your application requires the same level of precision relative to the size of the interval, rather than relative to the magnitude of values, then it’s better to use integers, which are evenly spaced.
Again, I’m not trying to lecture you (my sincere apologies if you had that impression), but I think that what you wrote initially was just too concise and could be misleading.
1 Like
Agreed. I might have been terse, but I still wouldn’t say misleading. 
1 Like
I tend to export as 8 bit tiff mostly for direct use in scribus (dtp), and scaled to the print size, so no further editing needed, if the image needs tweaks I go back to the raw editor, normally the next step for me after that is digital print (either short run digital offset or a C print), I’m not sure there’s much advantage in 16 bit for either process, I think the max number of colours for CMYK print is 16000 or something, and a c print I think is 3 or 4 colours
Yeah, that was coarse assumption on my part.
What’s probably more important is the establishment of a black-white convention. Playing with the algorithms, they don’t seem to care so much*, but the image eventually needs to be mapped to black-white and 0.0-1.0 doesn’t show up so well when the display is expecting something like 0-255…
*However, when I incorporated the librtprocess demosaics, I went ahead and converted my 0.0-1.0 to 0.0-65535.0 in case there was some aspect of the RawTherapee convention encoded in the algorithm…
I think this is what the exif fields SMinSampleValue and SMaxSampleValue are for. But I’m not sure.
Reads that way:
https://www.awaresystems.be/imaging/tiff/tifftags/smaxsamplevalue.html
I’ve just done a simple exiftool survey of TIFFs on my computer, none have these tags. 'course, the exporting software has to set them, I didn’t know until just now… 
For bounded data, sure. For unbounded, like HDR, you can’t know a priori what the max is for example.
The utility of those is not clear, as per above. Hence the no/slow uptake.
How many have loaded a 16-bit TIFF in G’MIC, and wondered why the image displayed all blown out? No problem, IIRC you can -cut it to the 0.0-255.0 range to which G’MIC defaults, and it still has good precision accounting to using floating point representation…
Indeed, unbounded data shouldn’t get a max anchor, yet…
Thank you all for your contribution to the thread. This is the kind of discussion I needed to read to get my head around the export options I should use. Yes I have asked Dr Google in the past but was left feeling little the wiser.
So my take home here is that TIFF remains one of the best output options except when a compressed JPG is required for obvious reasons. PNG seems to often match TIFF as an export option but there are some limitations to PNG which prevent it being a totally replacement for TIFF files. Also, my question about the 32 bit floating TIFF export option seems addressed well here. I probably only ever need it when I do HDR merge in another program and want to be able to further work the image in DT. That then brings up the point that with the improving dynamic range of modern digital cameras and the excellent ability of both filmic and sigmoid to work with the dynamic range of these cameras that I rarely feel the need to do HDR merging nowadays compared to the early days when I was an Adobe user and my cameras had less dynamic range.
Have a good weekend.
1 Like
Two other points.
PNG is an open standard, whereas TIFF is owned and licensed by Adobe - may not be important in your use, but is in some cases.
PNG can correctly signal HDR formats in the file header (Using ITU CICP) and can carry HDR10 style metadata. TIFF relies on a CICP chunk within an ICC profile. The PNG version is starting to be available in tools, whereas the new ICCmax/ICC V4 rollout seems to be slower.
The main problem with TIFF is it’s nature of being a container format. You can put uncompressed 32bit data inside or 10 JPGs. You won’t know until you open it. Formats like NEF and DNG are also based on TIFF, just as an example for the flexibility.
For those that dabble in music or film: would you guess the quality of an mp3 or mp4 file by it’s extension? Probably not.
The lossy options in PNG are very rarely used in practice so chances for “what you want is what you get” are much higher.
Edit: YIKES. What did they put into my water that I would write such nonsense. PNG is lossless by design, always. The compression options are just for different efficiencies and therefore computational effort.
I’m sorry.
1 Like
It is also one of its main advantages. Double edged sword that.
I use them all the time.
1 Like
That’s just being evil on purpose, right? 
There are usages with RGBA files where almost nothing else will do, but other than that: why?
See my edit above. 
People are using MS Word to send images, too.
Favourite story is where a colleague asked for the company logo to put it into a brochure he was designing for them and he gets a Word file … with a screenshot from the company website.
I have used tons of TIFF files but the multi-image container part rarely resulted in anything good.
In science the multi image ability of Tiff files is important for recording images from microscopes that have focus stacking. But that is a specialist use.
1 Like
And that, coupled with your initial phrasing, may be why you got so few answers initially, as @MStraeten gave the answer…
One thing that I did notice is that for comparable formats, TIFF tends to give much larger files than PNG.
And, in general, TIFF works well within one software package. When you try to exchange TIFFs with another package, you can get problems, as there are too many options, with very variable levels of implementation.
In the end I got lots of good answers including yours @rvietor. Thanks for your input. You are correct that TIFFs don’t always play nice between programs. My Canon printing software sometimes doesn’t open a TIFF file, but the problem can be fixed by opening the file in GIMP and resaving it as a TIF. I believe the issue is usually to do with information such as masks or thumbnail preview images being stored as layers within the TIFF file.