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). Nikon NEFs store full res previews while Canon uses half res, hence the larger fraction.

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. A 16MP 8bit image is 48Mb uncompressed.

Now to the point, since we are talking about jpegs here. It is the uncompressed bitmap size that is the base size for the compression to work its way down from , not the raw size. This means that if you set the compression to be very gentle, it can easily still be larger than the raw.

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. 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. I normally keep it at 80, which is 950k. And flipping between the 4Mb and the 950k file at 100% zoom, I can see no difference. So it seems like overkill that your 100% is barely compressing at all.

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. 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.