#Darktable export blurry full#

The discrepancy in size between JPEGs encoded at '100% quality' in different encoders is likely to be a result of one of the following:ĭifferent chroma sub-sampling setting. For your 24MP images you will probably hit that limit at around 1.5Mb, whichever the jpeg quality number that may be in your program.

So you should take an image with a lot of details and a clear sky, and save then at 100, 90,80,70,60,50, until you can see a quality hit. So it seems like overkill that your 100% is barely compressing at all. And flipping between the 4Mb and the 950k file at 100% zoom, I can see no difference. With the JPEGLIB that I use for my jpeg handling a 16MP image becomes 4Mb, and it quickly goes down to 1.7Mb at 95, at no perceivable quality hit. The jpeg quality numbers are arbitrary - all you know for sure is that quality 100 is larger than 90, and 90 is larger than 80 in the same program. This means that if you set the compression to be very gentle, it can easily still be larger than the raw. It is the uncompressed bitmap size that is the base size for the compression to work its way down from, not the raw size. Now to the point, since we are talking about jpegs here. So you can expect an uncompressed 16bit RGB 'bitmap' to be approaching 3 times larger than the raw, and times 3 divided by 2 for 8bit uncompressed.

#Darktable export blurry full#

Nikon NEFs store full res previews while Canon uses half res, hence the larger fraction. Uncompressed RGB files (3 values per pixel) will be larger than your raws, as the raws contain a monochrome bitmap (1 value per pixel), and usually a downscaled, aggressively compressed preview that takes a fraction of the size, 400k for Canon 10MP cameras, and 1M for Nikon D5100 (I know these numbers because I used to read them out of the raw files and store them in a temporary file).