DO11: Horrible JPEG viewing quality (blocking)

Help & Support
1

Hey guys,

I've got Directory Opus 11 beta 7 installed on Windows 7 64-bit, Intel i7-2600k CPU.

I'm having a lot of trouble with viewing JPEGs. The quality is absolutely atrocious, as there's a tonne of "blocking" i suppose you would call it.

I tried fiddling in a jpeglib implementation (jpeglib-turbo, speficially) of my own and can't find the combination of flags that produces the output i'm seeing from Directory Opus. Of course i don't even know if you're using jpeglib, but i'm sure the different implementations don't differ all that much. JPEG is JPEG.

I've attached a sample crop from an image viewed in Directory Opus, and what it looks like in every other application i have. That includes: Paint Shop Pro X6, ACDSee Pro 7, Chrome, and my own image viewing app.

I mentioned my CPU before just in case the problem is tied to optimisations that are dependant on hardware available.

Also, i could not find anything in Directory Opus's preferences that would indicate quality selection for JPEGs.

So, that's that, i guess.

I zipped the original .jpg and attached it to this post too. It's of a girl and i don't want to plaster cosplaying Facebook girls all over your forums. :wink: Hence the zipping.

Cheers,

Chris
Tasha Cosplay - Boa Hancock - One Piece_395905030438253.zip (66 KB)

2

Initially, I thought this might be a color management issue (since Opus ignores color profiles for RGB JPEGs), but although that makes the image darker in some programs than others, I don't think it's that.

I noticed that when I load the image into MSPaint (which doesn't do color management) and compare it to Opus, the colors are identical but there is JPEG "blocking" clearly visible in Opus that is somehow smoothed over in MSPaint.

But then I loaded the image into Adobe Photoshop CS4, and it shows the same blocking as Opus. IE and Firefox also seem similar.

It looks like the difference is some programs are blurring the red areas of the dress while others are not. I don't know why that difference is occurring (it could be several possibilities) but since Opus and Photoshop seem to agree, and Photoshop's JPEG handling is fairly definitive, I do not think it is a bug in Opus.

3

So, it's your contention that libjpeg, made and maintained by the Independent JPEG Group, whose work is arguably reference when it comes to JPEG (de)compression output, is producing wrong output? :neutral_face:

I checked Internet Explorer, Firefox, and Photoshop CS6. IE and Firefox look exactly like libjpeg, with no hideous blocking, so i don't know what you're seeing there. It's an overall low-quality image, so you're probably hurriedly looking in the wrong place. Indeed, however, Photoshop looks like Directory Opus with the hideous blocking artifacts.

Here is the list of programs that produce Directory Opus's hideous blocky output:
Directory Opus 11
Adobe Photoshop CS4 & CS6

Here is the list of programs that produce smooth libjpeg-like output:
libjpeg-turbo 1.3.0
Corel Paint Shop Pro X6
ACDSee Pro 7
Microsoft Internet Explorer 11 (Windows 7)
Mozilla Firefox 27
Google Chrome 33
XnView 2.13
Microsoft Paint (Windows 7)

I mean, you know, really? It's not a bug? libjpeg... libjpeg and basically everyone else is wrong? :neutral_face:

I realise that most of those programs probably use libjpeg, hence the libjpeg-like output. But.. Seriously that's a huge list vs a very very small list. It seems pretty obvious which output is considered standard. To think Photoshop is standard, despite vast proof that is not, would seem like misguided elitism.

Add on top of that that a tiny, tiny tiny tiny amount of all internet/computer users can actually afford and use Photoshop, whereas 100% of internet users have access to free libjpeg output from everyday apps.

Not to mention that Photoshop people are diehard about untouched detail, so it's likely that there is no smoothing happening because the users want to do their own post-processing on the JPEG output. Maybe Adobe purposely don't do it so that people can use plugins specifically for varied JPEG processing? I can imagine that could easily be the case. I don't know for sure, obviously, but it's certainly conceivable. You do know that depending on various factors (quality setting, subsampling, standard/progressive encoding), different processing must be performed on a JPEG image? It's not just one-size-fits-all.

The best and most obvious place to look in the JPEG, is at the red swirls under the girl's leg. It's extremely obvious when there's blocking artifacts. I don't know what you saw in Firefox and Internet Explorer, but i can provide screenshots to verify that they are indeed producing smooth libjpeg-like output. That would be a complete waste of my time though. Either you trust me on that or i implore you to look at them again, very closely so you don't miss it, at the red swirls, and rethink whether it "seems similar" to you.

4

Opus also uses libjpeg so your assumption that I am saying this is a libjpeg bug is bogus, sorry.

I also see the banding in some of your example programs. (How much you see may depend on color management settings. I found IE and Firefox both made the dress a lot more red/saturated than other software, which also washed out the blocking to a degree, but it was still there. I suspect they were using different colour profiles to Photoshop (my two monitors have different profiles and some apps seem to always use the primary monitor's profile).

5

Well then that makes it really, really easy.

You're obviously either using a faulty custom build, an old build, you haven't set up your options/flags correctly, or you didn't read the docs.

Try removing all custom options from your cinfo struct. Don't do a thing to it after jpeg_create_decompress(). Let it set itself up and do only the very basic decompression and tell me you're seeing the same blocky garbage output. Because i'm sitting here right now with a virtually ripped default "example.c" bit of code that produces brilliant smooth output like every app except Dopus and Photoshop.

6

How about we just admit that the red bit under her leg looks like absolute blocky shit (lol censored) in Directory Opus (and Photoshop)? Since Photoshop is not an image-viewing program, and since ALL other image viewing programs mentioned (Internet Explorer, Firefox, Chrome, ACDSee, XnView), and jpeglib's default (ie: example.c) implementation/options/flags display the red bit just fine and smooth without harsh macroblocking, how about Directory Opus just displays the image nicely like everyone else?

If you can't do that and insist on being all Photoshoppy, at least can we get an option (maybe in the advanced section) in Directory Opus to use jpeglib's default implementation? That should be so trivial.

That's not too much to ask is it?

7

It might be worth looking at some larger images - the enclosed example is very small and you have to blow it up considerably to see the "blocking". Without getting too Photoshoppy, it is best to view images at 100 per cent when dealing with quality issues.

At 100 per cent it is hard to form any kind of judgment on the lady in red - save to say she has a very fine par of legs.

8

Myself cannot find a difference in rendering between DO10, Photoshop CS2, MSPaint on Win7 and IE9 - I did look very close of course.

In your thumbnail-sized comparison, a difference is visible when magnified. But there is blocking/artefacts in both versions, it is "just" color being a bit different/darker in the "smoother" version, as Leo already said.

9

Maybe i sit closer to the monitor than you guys. Maybe i have better eyesight. But the macroblocking under her legs is hideous and noticeable without any magnification, to me. That screen capture comparison i made was not magnified at all, and i can see the difference as plain as day sitting here looking at it normally.

Regardless of whether your eyes are capable of seeing the harsh "block boundary artifacts" (technical term for it i believe that's quite accurate in literal meaning), they still exist. If you can't see them, then it won't hurt you to have them smoothed like they are by libjpeg in its default configuration, since you can't see the detail anyway.

The colour of the image is irrelevant to the topic. Maybe one of them did some gamma correction, maybe one of them messed with colour profiles. It doesn't change the fact that there are block boundary artifacts. It's quite literal in that you can see the boundary of the macroblocks used in compression. They look terrible, even with no magnification. It's like the image is made of lots of small misaligned squares in a grid. I don't see how it can't be obvious to you guys. I guess it's image quality perception. Some people can see this stuff, some people can't. Some people can live with 4GB "HD" videos off iTunes.. Some swear by 50GB of high-bitrate AVC straight from the Bluray disc. That's what JPEG and all this stuff was designed for anyway, to fool the eye into believing it's the correct original image.

As to "larger images" (dimension? filesize?), it's moot because this problem seems to only happen on highly compressed images. ie: From Facebook. ie: Images that will have block boundaries that will need smoothing because they've been compressed too far. I can find other images that exhibit similar artifacts, but really i don't see the point.

Let's not argue about who can see what. If you can't see the difference then it doesn't matter to you anyway.

Just.. Please.. An option in the advanced section for default jpeglib processing. That's all i ask. Not even enabled by default, so you guys can keep your Photoshop "quality".

10

Chris, nobody said there are no blocky artifacts. They are clearly visible, but they are in BOTH versions. So maybe its your eyes? Your "smooth"(er?) example is artefacts-wise equally bad to your "blocky" version - at least to me. The smoother version is just not that saturated / has different color, whatever the reason is for that, but to me this is more of a "color" than "block" problem. Maybe I try some color adjusting when home from work to proof that.

Until there is detailed knowledge about what exactly goes on here, you might simply ask for equal rendering (without telling people what they might not see or should do).

Having images equally rendered btw., is something I can totally understand.

11

The image contained in the zip attached to the original posting has an ICC colour profile called C2 attached to it. This could possibly go some way to explaining the differences when viewing the picture in different programs, particularly as DOpus does not support ICC profiling. I am not familiar with profile C2 so it could literally be anything.

But I can assure Chrisp that if you take a decent 26meg file from a digital camera. compress it to a jpeg in Photoshop to quality 9 and then view the result in Photoshop and the DOpus image viewer,on a properly calibrated monitor (Eye-one Match) the only difference you will see is caused by the lack of support of ICC profiling in Dopus.

I would be much more worried about the artifacting caused by the small image size than the block boundary artifacts. Whatever you say about JPEG, it is a lossy compression algorithm. Try cropping bits of a JPEG picture and the re-compressing it a few times.

If you are looking for good quality JPEG images you need to create them properly. Garbage in garbage out.

12

I had a little investigation on that comparison image. If you zoom in very very close and sharpen up the image a bit, you can make out an interesting difference.
It then isn't overall color anymore, it is the actual pixel information which is different.

In generel it looks like, as if in the upper image, each block is smoothed to its surrounding blocks - some kind of block-antialising. If you look at the edges of the blocks, they show very different color, but even in the center of each block, you can make out changes in color and rendition.

I'm no way deep into technical details on image processing nor jpeg decoding, so you might not take this seriously, but from my point of view (which has changed now), this is indeed something more related to rendering the pixels/blocks and not related to a color profile. FWIW, i never had problems the way DO displays my jpgs and I do look very closely very often, as I take a lot of pictures with digital cameras and stuff. The image shown, probably is compressed at jpg quality setting of around 15-20%, something I do not handle, not even when publishing images as small as can be (size wise) to the internet.

The attached image shows two jpg "blocks" magnified and zoomed in for detail inspection:

13

When you say "everything else", which software are we talking about?

Photoshop CS4 here seems to give the same results (ignoring color profile adjustments) as Opus, for example.

14

We do use the default settings. We call jpeg_read_header() which initializes the jpeg_decompress_struct to defaults, and we don't change anything in it after that.

I've attached a dump of the live jpeg_decompress_struct for your picture from immediately before the call to jpeg_start_decompress - feel free to compare it to your own implementation.
cinfo.txt (7.08 KB)

15

It's already been said but i'll say it again:

libjpeg-turbo 1.3.0
Corel Paint Shop Pro X6
ACDSee Pro 7
Microsoft Internet Explorer 11 (Windows 7)
Mozilla Firefox 27
Google Chrome 33
XnView 2.13
Microsoft Paint (Windows 7)

All of these programs produce the smoothed over look on my computer. The cropped image in the first sample image was taken from one of those programs, i can't remember. But since they all produce smoothed output, it really doesn't matter. The "libjpeg-turbo" example is my own program that doesn't touch/mangle the cinfo struct at all during the decompress and produces the (almost) exact same smoothed default output as most programs out there.

I'm glad it's being recognised that it's pixel differences, not colour. I never said it was about colour anyway.

Also to verify colour profiles not being an issue, i loaded the image into Corel Paint Shop Pro X6 with and without embedded colour profiles enabled, and it made no difference to the smoothness of the image.

Jon, if you are indeed using default options and not touching your cinfo (and yes i can't see anything abnormal in your .txt file), then do you want to elaborate on what version of jpeglib are you using? Is it the latest? (v9a) Do you build your jpeglib .lib with any custom options in jconfig.h etc? My jpeglib-turbo is all defaults, with nothing touched. Do you use jpeglib-turbo? If you don't, you should, because it has been widely adopted.

Also, i would wager all of those programs above producing smooth output are using default options too, since my output matches their output.

Your output does not match the majority output. So, you must be doing something different. Different version, different build, non-default options, jconfig.h mangled, whatever.. Something's different. There's no denying the pixel differences in my sample image. Bend in close to the monitor if it's not clear to you and look at the red swirls. It's a low-quality JPEG anyway so you will see some form of blocking. It's just, is it harsh high-contrast macroblocking, or smoothed over and almost-natural looking.

I could make guesses all day as to what you've done different to almost everyone else (except Adobe), but ultimately that knowledge is yours and you need to share it.

16

We haven't changed any of the default settings. We're currently using v8a. Maybe libjpeg-turbo has a smoothing filter or something that's enabled by default?

17

Working on that right now actually.. I'm going through all my config.h, jconfig.h, jpeglib.h, jmorecfg.h, etc and rebuilding trying different things to get Adobe/Dopus output. There's some promising options but i'll need some time to test all these builds. I'll let you know what i find.

18

I was asking tbone which software he'd tried, BTW, since he also posted a screenshot saying "everything else" but I wasn't sure which software had been tried.

19

This is bizzare.

I just dropped jpeglib 9a in jpeglib-turbo 1.3.0's place and it produces blocky Dopus/Adobe output. Switch back to linking to jpeglib-turbo with absolutely no code change: back to smooth output.

So far there's nothing i've done that makes jpeglib produce jpeglib-turbo's output, or vice versa.

jpeglib-turbo just looks better by default. :neutral_face:

I'll keep trying things.. But is there any chance you guys will consider adopting jpeglib-turbo? It's much faster than jpeglib and it's quite obvious that the vast majority of big programs out there (except Photoshop) have adopted it, since they're all producing the smooth output. Obviously it would be a PITA to make your JPEG support dynamically instead of statically linked, but if you insist on defaulting to vanilla jpeglib, it would be nice and probably the only way to be able to switch implementations at runtime by just switching the DLL out.

I can't find any mention of this jpeglib vs jpeglib-turbo quality difference on Google at all..

Sigh. I don't know.. I'll keep trying different options i guess. :frowning:

BTW Leo, i thought tbone just altered my sample image, so his "everything else" is actually my "everything else". At least that's what i assumed.

20

Heh, it's kind of ironic that i accused you guys of not doing "reference" jpeglib output, when it turns out it's everyone else (including me) not doing reference output.

My bad. :blush: And sorry.