Does synthetic noise make a photo harder to compress to 100KB?

In one controlled test of one 3000 × 4500 photo, deterministic per-channel RGB perturbations made the re-rendered PNG inputs larger, from 18,232,592 bytes at the zero-perturbation control to 38,760,649 bytes at the ±24-level setting. At the 102,400-byte JPG target, outputs stayed between 101,745 and 102,324 bytes and did not increase monotonically with perturbation. The source for these measurements is 本机合成像素扰动 (local synthetic pixel perturbation), not measured camera sensor noise, and it does not establish a general result for photographs.

Was real camera sensor noise tested?

No. The test started from one local 3000 × 4500 JPEG, drew it to a canvas, and added deterministic independent per-channel RGB perturbations to make synthetic PNG fixtures. These fixtures do not model a camera sensor, an ISO setting, a sensor's noise pattern, or every image-processing pipeline.

What does the 100KB target mean here?

The tool's 100 KB setting is 100 × 1,024 = 102,400 bytes. The twelve measured JPG outputs were 101,745 to 102,324 bytes, all at or below 102,400 bytes. They are all above 100,000 bytes, so this result does not meet a separate decimal 100,000-byte limit.

Does the MAE value tell me whether the compressed photo looks good?

No. MAE here is the mean absolute RGB-channel difference on the output-sized pixel grid, with channel values from 0 to 255. It compares decoded pixels with a resampled reference; it is not a human visual-quality rating and does not include all spatial detail lost when dimensions are reduced.

Were the results repeatable, and were the times identical?

Each of four synthetic fixtures was compressed in three fresh tabs. Within each fixture, output bytes, dimensions, encoder parameter and error readings matched across all three runs. The tool times and independent wall-clock times varied; all three readings are listed on the page and are not performance guarantees.

Compress JPEG to 100KB: What Synthetic Pixel Noise Changes in a Photo

Q: Does this page also cover compress JPEG to 100KB?

Yes. The phrase compress JPEG to 100KB describes the same photo-compression intent covered here, not a separately measured workflow or page. The base 3000 × 4500 photograph was a JPEG; it was decoded, re-rendered into PNG fixtures with synthetic RGB perturbations, and encoded as JPG at a 102,400-byte setting. This is one photo and one browser, not a JPEG-versus-format comparison.

A 100KB ceiling is fixed, but a photo's fine pixel variation can change what the compressor has to work with. I took one 3000 × 4500 photograph, made four PNG versions with controlled synthetic RGB perturbations, and compressed each to the same JPG target three times. The input PNG grew from 18,232,592 B to 38,760,649 B as the perturbation increased, yet the twelve JPG outputs stayed between 101,745 B and 102,324 B. The output bytes did not rise steadily with the added noise, and the highest setting returned a slightly smaller pixel grid. This was synthetic pixel noise on one photo, not camera sensor grain.

If you searched for compress JPEG to 100KB, this page covers the same photo-compression intent rather than a separate format comparison: the base photograph was a JPEG, re-rendered as controlled PNG inputs, and then exported as JPG. The measurements below do not compare JPEG against other output formats.

How the controlled inputs were made: the base file was one 3000 × 4500 JPEG (2,243,536 B). It was decoded with orientation applied, drawn to a canvas and exported as PNG. The control (amplitude 0) is that re-rendered PNG, not the original JPEG bytes. The other fixtures added deterministic, independent, uniformly distributed changes to each R, G and B channel in [−a,+a] 8-bit levels, then rounded and clipped values to 0–255. Each fixture was compressed as JPG at the tool's 100 KB setting (102,400 B) in three fresh tabs. These generated pixel changes do not reproduce a real camera sensor, its spatial or color pattern, or a particular ISO setting.

Four inputs from one photograph

Holding the source photograph and dimensions constant makes this a controlled comparison, but it does not turn four synthetic versions into four independent photographs. The perturbation amplitude is the maximum per-channel range; the measured mean absolute change in the generated fixtures is listed separately. Increasing the amplitude increased the byte size of these PNG fixtures, but that observation belongs to this one image and this canvas-to-PNG path.

Fixture	RGB perturbation	Measured change MAE	PNG input B	PNG vs control
Control	0 levels	0.0000	18,232,592	—
Synthetic 08	±8 levels	4.0000	33,920,754	1.86×
Synthetic 16	±16 levels	8.0007	36,562,984	2.01×
Synthetic 24	±24 levels	11.9979	38,760,649	2.13×

Measured fixture bytes are disk sizes; the same byte counts were reported by the browser File object. “Measured change MAE” is the mean absolute difference between each generated fixture and the decoded, orientation-correct base on the original 3000 × 4500 grid, averaged over RGB channels. The ratios in the last column are arithmetic: each PNG input byte count ÷ 18,232,592 B. The 40,500,000 RGB channel samples per fixture are the 3000 × 4500 pixel grid × 3 channels.

The PNG byte count is not the photo's pixel count. All four fixtures remained 3000 × 4500 pixels, or 13,500,000 pixels. What changed was their decoded RGB content and how that content was represented by this PNG export. This experiment did not compare PNG encoders, different source photographs, or real camera sensor patterns.

Twelve JPG compression runs at one ceiling

Each fixture went through the browser compressor three times, always in a fresh tab. The 100 KB setting in this tool means 100 × 1,024 = 102,400 bytes. Every recorded output is under that binary ceiling, but all twelve outputs are above 100,000 bytes. The encoder parameter was 0.4046875 in every run; it is not a visual-quality score. If a form means exactly 100,000 decimal bytes, these outputs would not meet it.

Fixture	Run	Input PNG B	Output JPG B	Output px	JPG q	MAE vs input	MAE vs clean	Tool ms	Wall ms
Control (0)	1	18,232,592	101,885	1024 × 1536	0.4046875	4.0661	4.0661	2,375	2,510
Control (0)	2	18,232,592	101,885	1024 × 1536	0.4046875	4.0661	4.0661	2,007	2,155
Control (0)	3	18,232,592	101,885	1024 × 1536	0.4046875	4.0661	4.0661	2,155	2,298
Synthetic 08 (±8)	1	33,920,754	102,324	1024 × 1536	0.4046875	4.3157	4.0718	2,164	2,256
Synthetic 08 (±8)	2	33,920,754	102,324	1024 × 1536	0.4046875	4.3157	4.0718	2,142	2,243
Synthetic 08 (±8)	3	33,920,754	102,324	1024 × 1536	0.4046875	4.3157	4.0718	2,113	2,315
Synthetic 16 (±16)	1	36,562,984	101,745	1013 × 1519	0.4046875	4.8908	4.1231	2,347	2,386
Synthetic 16 (±16)	2	36,562,984	101,745	1013 × 1519	0.4046875	4.8908	4.1231	2,788	3,012
Synthetic 16 (±16)	3	36,562,984	101,745	1013 × 1519	0.4046875	4.8908	4.1231	2,257	2,305
Synthetic 24 (±24)	1	38,760,649	102,114	1002 × 1502	0.4046875	5.6046	4.2398	2,139	2,214
Synthetic 24 (±24)	2	38,760,649	102,114	1002 × 1502	0.4046875	5.6046	4.2398	2,959	3,029
Synthetic 24 (±24)	3	38,760,649	102,114	1002 × 1502	0.4046875	5.6046	4.2398	2,426	2,565

All rows were measured 14 November 2026 on local Windows 11 / Chrome 157.0.8103.78. Output bytes were checked by the compressor report, FileReader and the saved disk file. Dimensions were checked against createImageBitmap. “MAE vs input” compares the decoded output with the corresponding perturbed PNG drawn to the output dimensions; both createImageBitmap and HTMLImageElement output-decoding paths agreed for every run. “MAE vs clean” compares with the unperturbed base photo drawn to the same output dimensions and decoded through createImageBitmap. MAE = sum of absolute RGB-channel differences ÷ (output width × output height × 3), with channel values from 0 to 255. It is not a perceptual score. Tool time is the compressor's “Done in … ms” value; wall time is an independent Date.now() bracket. All three original readings are shown.

The output did not track the input bytes

The synthetic 24-level PNG was 2.13 times the zero-perturbation PNG size by the arithmetic above, but the corresponding JPG did not become 2.13 times larger: it was 102,114 B rather than 101,885 B. More importantly, the four output sizes were 101,885 B, 102,324 B, 101,745 B and 102,114 B. They do not form a steadily rising sequence as perturbation amplitude rises. The byte ceiling constrained each result, and the compressor's chosen dimensions and encoded content also varied.

The control and ±8 fixture both returned 1024 × 1536. The ±16 and ±24 fixtures returned 1013 × 1519 and 1002 × 1502. From the control to ±24, the final grids contained 1,572,864 and 1,505,004 pixels respectively; the latter is 4.31% fewer by arithmetic: (1,505,004 − 1,572,864) ÷ 1,572,864 × 100. That difference is measured on this one experiment. It is not evidence that a real camera's grain will always make a 100KB compressor remove more pixels.

Two error references answer different questions

“MAE vs input” asks how the output's final pixels differ from that fixture after the perturbed input is drawn to the output grid. “MAE vs clean” instead compares with the unperturbed base photo on that same grid. At ±24, those readings were 5.6046 and 4.2398 per RGB channel. The output was numerically closer to the clean reference in this comparison, but this run does not separate the effects of downsampling, JPEG encoding and the synthetic perturbation. It therefore cannot identify which step explains the difference or claim that a compressor universally removes sensor noise.

The clean-reference MAE rose from 4.0661 at the control to 4.2398 at ±24, a difference of 0.1736 levels by arithmetic (4.2398 − 4.0661, using the unrounded readings in the raw file). This is a small change in this metric for this sample; it does not mean a viewer would or would not notice it. The metric uses the final output-sized grid and does not count all detail lost by reducing the image dimensions.

What to take from a 100KB photo result

Check the exact byte rule. This tool's 100 KB setting is 102,400 B. Every output here was under that ceiling but above 100,000 B; a decimal 100,000-byte form needs a stricter target.
Read the returned dimensions. The four outputs ranged from 1024 × 1536 to 1002 × 1502. The target label alone does not promise one output resolution.
Inspect the downloaded file at its use size. MAE describes averaged channel differences on a defined grid; it cannot replace checking the detail that matters in a portrait, scan or other photo.
Do not treat the synthetic-noise table as a sensor-noise forecast. It isolates a controlled pixel perturbation on one base image. A real camera's noise structure, denoising, exposure and source format were not tested here.

Questions this test can answer

Does added noise make any image impossible to compress to 100KB?

This experiment cannot answer that for every image. All four generated PNG fixtures produced JPGs at or under 102,400 B, with outputs from 101,745 to 102,324 B. The fixtures came from one photograph and synthetic changes; they do not cover all subjects, cameras, formats or browsers.

Did the compressor return a 100,000-byte file?

No. It used the site's 100 KB setting, which equals 102,400 B. The measured JPGs were all within that ceiling but ranged from 101,745 to 102,324 B, so each was above a 100,000-byte decimal limit. Check the destination's actual definition of KB before submitting a strict upload.

Does this show that phone photos with grain always lose more pixels?

No. The added changes were deterministic synthetic values, not an image shot at a different ISO and not a measured sensor pattern. Only one base photograph and one browser/encoder were tested. The dimension changes here are observations from those twelve runs, not a general rule about phone photos.

Was the time result repeatable?

The file outputs repeated within each fixture, but time did not. Tool readings for the control were 2,375 / 2,007 / 2,155 ms and wall readings were 2,510 / 2,155 / 2,298 ms. The full table shows the same three readings for every other fixture; these are local environment measurements, not promised runtimes.

What is a low MAE supposed to tell me?

It tells you the mean absolute RGB-channel difference for the stated reference and pixel grid. Here the original and output were compared after drawing the reference to the output dimensions. MAE does not say whether a human considers the result sharp, attractive or useful, and it does not include the full spatial detail discarded by downsampling.

Does this page also cover “compress JPEG to 100KB”?

Yes. That phrase describes the same photo-compression intent, not a separate measured workflow or a new page. The base 3000 × 4500 photograph was a JPEG, re-rendered as controlled PNG inputs, then exported as JPG at the 102,400-byte setting. This test does not compare JPEG against other output formats.

This controlled synthetic-noise run asks what happens to one photo's encoded output at a fixed 100KB target. The separate compress image to 100KB measurement compares whole-frame and cropped versions to examine a dead sky band and subject-region error; it does not use this noise fixture. For seven different source files, resize image to 100KB reports returned geometry and pixel retention. The email compression test measures selected EXIF fields in synthetic metadata fixtures, not image noise.

Measurement provenance: 本机合成像素扰动 (local synthetic pixel perturbation) only. Base photo _testimg/s1m-photo-3000x4500.jpg; generated fixtures, compressor runs and raw measurements _px37_photo_noise_out.json; runner _px37_photo_noise.js. The source was re-rendered on canvas before deterministic RGB changes were applied. Local Windows_NT 10.0.22631 x64 / Chrome 157.0.8103.78, 14 November 2026. Not a real camera sensor-noise sample.

Compress a photo or JPEG to 100KB