Hacker News new | past | comments | ask | show | jobs | submit login

I'll leave it up to you to determine which is which. The results are undeniably atrocious.

http://i.imgur.com/kadvgkyh.png

http://i.imgur.com/OGvb2vM.png

(Yes, the file name is the same in both because I imported the two and switched the layers on and off.)




When JPEGMini came out I thought it was a hoax. I've been working with various image compression tools since 1992, and was highly skeptical about their claims, but after encoding a ton of edge cases, I was convinced it was the real deal.

Have since encoded thousands of images for various clients with JPEGMini, and have never noticed ANY difference or persistent issues. Most of all, it saves me from having to experiment with individual image optimization settings. I always use it as a last step in every development project (last step because it has the annoying 'feature' that it overwrites the originals).

I dare you... Give me the original JPEG of your PNG samples (you DID start out with a JPEG, right?) and I'll repeat your experiment with my local JPEGMini install, then upload them to IMGUR for re-post here.

As to the issue at hand (Beamr/Snake-Oil): if Beamr saves me the trouble of manually having to fiddle with all kinds of optimization parameters to get very good result, much more difficult for video than JPEG, because scenes and requirements change, then that too is worth my time and money.

To be clear: I have nothing to do with Beamr or this company. I've been lurking around on HN for a long while, check my profile. The original Diaz post and claims like yours are simply a load of crock.

PS I know you can get better compression results with JPEG2000 and various more obscure formats, but the clincher for me has always been that the end result was straight ole JPEG. Works everywhere.


 > The original Diaz post and claims like yours are simply a load of crock.

 > you DID start out with a JPEG, right?

I hope you like My Little Pony.

 > then upload them to IMGUR for re-post here

I wouldn't try uploading JPEG images to Imgur, they get put through a compressor.

Original — http://d.pr/GIWO+

Lossy — http://d.pr/XIUf+


Ignoring the fact that the original image [1] had banding issues (e.g. top left), and ignoring the fact that JPEG is a format which optimizes file size by taking advantage of the limitations of the human eye as well as typical properties of REAL photographs (ie NOT cartoons, and NOT images with largely the same tone {'orangy' in this case}), I think you have to agree that my result from the standalone JPEGMini app [3], is markedly better than your "lossy" example [2]

[1] https://dl.dropbox.com/u/139377/ThreePonies/00-ORIGINAL.jpg (1.8MB)

[2] https://dl.dropbox.com/u/139377/ThreePonies/01-YOUR-LOSSY.jp... (121kB)

[3] https://dl.dropbox.com/u/139377/ThreePonies/02-MY-LOSSY%28JP... (410kB)

Your lossy sample is brighter, has major artifacts around pointy hair bits, the sickle, etc. and in zoomed in mode, which is not how you should compare these things, there's a distinct lack of detail.

If you were to repeat the same comparison with a realistic photo, the differences between the original and the jpegmini version, there are some, but you have to look hard, would be even less noticeable.

Please note: JPEGMini does not allow me to set any parameters at all.

In short: a single drag/drop on my part reduced a file from 1.8MB to 410kB and differences are extremely minimal. Another win for jpegmini.


 > is markedly better than your "lossy" example

I used the exact same application as you did. JPEGmini lite from the App Store. I'm not sure what could account for the discrepancies between our examples. As you mentioned, there's no possible parameters either of us could have changed.

 > and in zoomed in mode, which is not how you should compare these things

I see no issue with zooming to demonstrate already visible compression artefacts.

 > ie NOT cartoons, and NOT images with largely the same tone

JPEG compression actually looks better on images with flat areas of color of gradient. This can be demonstrated by exporting an image in the format with and without a very slight gaussian blur added to the image. The results are typically a good deal smaller with the blur applied.


> I used the exact same application as you did. JPEGmini lite from the App Store. I'm not sure what could account for the discrepancies between our examples. As you mentioned, there's no possible parameters either of us could have changed.

I used the non-lite version (ie I paid for it). Version 1.4.2 to be exact (I see the latest version is 1.4.3). Not sure if the "full" and "lite" version are using different compression levels or algorithms. I do know that older versions had a much lower megapixel limit.

> I see no issue with zooming to demonstrate already visible compression artefacts.

I do, because that's the crux of the story. JPEGMini (and Beamr too I guess), provide VISUALLY similar results with smaller file size and with a minimum of effort required.

Loss of information is inherent to lossy compression. Achieving a file size reduction requires that sacrifices are made somewhere, typically by removing detail. The trick is making these sacrifices in the right places, so that before and after appear the same.

If the processed image is displayed at 800x600 on a monitor with 150DPI, one would make different choices/assumptions about what to sacrifice than if the resulting image is viewed at 300% magnification. JPEGMini's feat is making the right sacrifices (note that they do NOT change the compression method, the end result is a STANDARD jpeg file, not a special format).

> JPEG compression actually looks better on images with flat areas of color of gradient. This can be demonstrated by exporting an image in the format with and without a very slight gaussian blur added to the image. The results are typically a good deal smaller with the blur applied.

Correct, but photos are still very different from cartoons, vector graphics, text, etc (think: colors occurring in nature vs colors picked by a designer, inherent blurriness of large parts of a photo, very few hard edges in most photos, the human visual model - color, luminance vs chrominance, filling in the gaps etc etc).


To add to my my point, check out these two real pictures, hope you like pink bags:

OriginalPony [1] - 451kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-origi...

JPEGMiniPony [2] - 151kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-jpegm...

Now tell me, where is the banding?

(CC, source: http://www.flickr.com/photos/dreamcicle/3552305929/sizes/l/i... )


You picked the wrong input to prove your point.

That image has too much noise. You need smooth gradients to get banding. The pony, the smoothest part of the image, has a lot of sensor noise (more chroma than luma but still) in the 3-6 pixel frequency range.


I was trying to prove my photo point ("If you were to repeat the same comparison with a realistic photo, the differences between the original and the jpegmini version, there are some, but you have to look hard, would be even less noticeable.")


There's certainly less impact on that image. The lower left section looks awfully blocky, but that's somewhat to be expected given the size of the image. The main difference in all of these examples is the loss of CCD noise, which could be considered a good or bad thing depending on your aim.


You damn shill. Stop peddling your wares on YC!


Man, you need to do your homework. Throwaway account to accuse me of something? Flagged bro. I've been here for 4+ years. Loser.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: