Weird Crop tool behaviour with 16-bit files

[erickellerman]

Shadow areas of my 16-bit files show strange patterns if I use the Crop tool to rotate. I can also replicate the problem by doing the following:

Make a new empty 16-bit file in PS6 in RGB mode (File>New). Fill it with 100% black. Use the Crop tool and rotate to taste. Press Enter to accept the crop and zoom in to enjoy the black and grey noise patterning reminiscent of a man's suit. The Straighten tool will achieve the same result. Your suit pattern will vary according to the degree of rotation.

The problem goes away if you subsequently convert the file to 8-bit, or convert to any other mode (Greyscale, Lab, CMYK).

This patterning is easily visible at 100% view or less, and appears whether the View>Show>Pixel Grid option is on or off. It is decidedly NOT the pixel grid I am seeing.

This effect can be created with files from both my Canon and Hasselblad cameras.

I'm using a Mac Pro with OS10.6.8.

[Hudechrome]

It's a good question and since printer drivers run at 8 bit, probably not. There is a Canon printer that will run at 16 bit. That's the one to try.

But these are phantom images as a result of video card interactions. The video card is not in the path to the printer (AFAIK!)

[conroy]

Hudechrome wrote:

I don't think Adobe can be held responsible for video drivers making errors

I agree that Adobe is not responsible for OpenGL errors in a GPU's software.

However, tiny but nevertheless real errors are being generated into the transparency of pixels in the document by Adobe's bicubic resampling code in 16-bit mode. Without these errors in the first place, the transparency grid blending errors in the GPU software would not be in effect. The most important bug(s) to fix are those in the Adobe bicubic resampling code.

More to the point, these errors contaminate the 16 bit presentations, not 8 nor 32.

Not entirely true. As I told you yesterday, the tiny Adobe-generated transparency errors remain in the pixels' transparency when you switch from16-bit to 32-bit mode and the display artefacts are still faintly present in 32-bit mode.

Switching the mode from 16-bit to 8-bit does remove the transparency errors because the errors are in the lowest bit(s) of the 16 bits and the lowest 8 bits are discarded when converting from 16-bit to 8-bit. When these Adobe-generated errors are eliminated, the GPU software produces a correct display. The GPU problem is only apparent when pixel transparency is a very small amount greater than 0; a smaller number than can be represented by 8 bits. You can check that by converting a "corrupted" 16-bit document to 8-bit then to 16-bit again. The display will now be clean because the pixels whose transparency was a minuscule amount greater than 0 now have a transparency of exactly 0.

Further, this action is unidirectional, that is reducing the size does not produce the artifact.

That's incorrect. The bicubic resampling errors happen when upscaling and when downscaling.

As to large start values in the pixel number. it appears not to be present. But increasing the magnification past 65% does show it up. Example: Start  2000x2000 px. Increase size to 3521 px. Image looks clean

No, I disagree. The problem is visible with your specific example.

BTW, I still cannot use Exposure or Curves to amplify these artifacts. there is no change; the background remains dark unless I use the gamma slider, at which time the background changes to gray with no artifacts showing. I must be missing a step or two.

When you said that yesterday also, I replied that I was enhancing the artefacts by increasing the exposure of a screenshot of Photoshop that I had captured when the artefacts were being displayed, and not by increasing the exposure of the resampled layer in the document. To what are you applying an exposure adjustment that doesn't enhance the artefacts?

[Chris Cox]

>> The most important bug(s) to fix are those in the Adobe bicubic resampling code.

You're talking about 1 bit errors in the least significant bit of a 16 bit calculation, which are only visible when extreme adjustments are applied or a display driver bug is involved.  That's not a major problem.  It will be addressed, but there are much more pressing matters ahead of it in the queue.

The big problem here is the GPU issues making those LSB errors visible - that needs to be fixed soon.  I still can't say for sure whether this is an Adobe bug (failing to account for certain GPUs), or a driver bug on certain GPUs.  But we will continue to investigate.

[conroy]

Chris Cox wrote:

>> The most important bug(s) to fix are those in the Adobe bicubic resampling code.

You're talking about 1 bit errors in the least significant bit of a 16 bit calculation, which are only visible when extreme adjustments are applied or a display driver bug is involved.

Yes, I certainly am talking about the 1 bit errors. If these 1 bit errors created by Adobe's bicubic resampling weren't present then the suspected display driver bug would never have a visible result whether that display driver bug exists or not.

It seems that the display corruption doesn't arise unless only the least significant bit of 16 is set in a pixel's transparency.

The Adobe error is the initial error in a chain of errors. Eliminate that initial error and there will be no display problem regardless of the display driver.

---

This is an edited form of a now deleted post.

[Hudechrome]

Are there any resampling algorithms other than bicubic suitable for resizing that does not show these artifacts? And FAPP, the main problem is that confusion as to true artifacts visible in printing and those visible on the screen interfering with corrective measures. It's no small consideration.

My bad missing the screen shot as the source for Exposure change.Unfortunately, that would be no aid to clarifying the confusion factor in real time.

We disagree on what we see. My assertion concerning the 2k x 2k resample sighting stands for this equipment. It literally snaps into view as the magnification changed from around 65% to beyond 66%.

I'll not bother much with those differences, leaving all this up to Chris and his people.

Bottom line: Dupe the 16 bit file flatten and reduce to 8 bits when doing noise and artifact checking on a given image. I'm going back to certain files and look in the next few days.

[conroy]

Hudechrome wrote:

Are there any resampling algorithms other than bicubic suitable for resizing that does not show these artifacts

Bilinear and Nearest Neighbor don't have the problem, but you probably won't like Bilinear's inferior results and you almost certainly won't like Nearest Neighbor. Try them, though. You are the one who has to decide what looks acceptable.

And FAPP, the main problem is that confusion as to true artifacts visible in printing and those visible on the screen interfering with corrective measures. It's no small consideration.

Yes, certainly.

We disagree on what we see. My assertion concerning the 2k x 2k resample sighting stands for this equipment. It literally snaps into view as the magnification changed from around 65% to beyond 66%.

If "Cache Levels" is greater than 1 (which it is by default) in Preferences > Performance, the display calculation of 16-bit documents is streamlined to 8 bits when zoom is less than about 65%. Therefore the artefacts will not appear below that zoom level and will suddenly appear when you go over that zoom threshold into 16-bit display calculation.

[Hudechrome]

I was thinking of other than PS for resampling, like Fractal Images. But thnks for the heads up about the others in PS.

I just tried the 2k x 2k resampled to 3521 setting Cache to 1 and got the same result. Specifically, no artifacts at 63.26%, artifacts visible at 64.84% and above.

Conventional wisdom anyway is check 100%.  So I checked again at 100% with a 5k x5k file resampled up to 7531. At 100%, it is visible. Cache size not a factor.

[Noel Carboni]

Trouble is, it's not just image size resampling but anything that uses resampling that's affected.  Hence rotating while cropping is implicated in the thread above.

As for whether it's purely a display driver fault, I'm not completely willing to believe Adobe has no fault in this.  Has anyone got a GPU on which the problem doesn't happen?

-Noel

[Hudechrome]

I wondered about that as well, Noel. You and I are running Ati cards. I don't know where you have landed with their drivers but I amusing the latest, 12.8

[conroy]

.

Repost with proper screenshots (there was a conversion problem)

Hudechrome wrote:

I just tried the 2k x 2k resampled to 3521 setting Cache to 1 and got the same result. Specifically, no artifacts at 63.26%, artifacts visible at 64.84% and above.

Conventional wisdom anyway is check 100%.  So I checked again at 100% with a 5k x5k file resampled up to 7531. At 100%, it is visible. Cache size not a factor.

Cache size is a factor when the zoom is below about 64% here, which entirely accords with how the 16-bit mode display is streamlined to 8-bit calculations below that zoom threshold when Cache Levels is greater than 1. Artefacts popped into the display of Cache Levels 4 only when zoom was 63.77% or greater, but they were always visible with Cache Levels 1, as expected.

Here are screenshots to illustrate.

[Hudechrome]

"...but they were always visible with Cache Levels 1, as expected."

What part of "Not here" don't you understand? I am getting different results due to what I don't have a clue, nor do I really care. !00% has no competition. In fact, all tests run using a pixel count from 1024 x1024 down will be at 100% or greater if you use "fit screen" or Ctrl +Alt 0. So I leave my cache at four, run at 100%, the measurement problem resolves, so far as visuals are concerned.

Years ago, I had serious problems with a design I implemented using image mirroring. The file size got great but I didn't watch at 100%. I thought I had a design with burgundy as the central color but either flattened or 100% I had mustard.

You might say that didn't cut the mustard at all!

[conroy]

Hudechrome wrote:

What part of "Not here" don't you understand?

Look who's talking!

Read my first sentence. I deliberately preceded my results with the word "here" just as you did.

[Hudechrome]

Well, you were repeating yourself. I can only assume by doing that, you didn't understand my response, didn't care, whatever.

Also I did NOT use that "smiley" in the sentence you quoted.

Give it a rest. I'm done.

[conroy]

Hudechrome wrote:

Well, you were repeating yourself. I can only assume by doing that, you didn't understand my response, didn't care, whatever.

Your assumption was wrong.

Repeating myself? You posted information that your findings were different from mine. I could have been in error so I posted some evidence of what I was getting on my system. Please don't be upset by me posting something contradictory to your post. It wasn't a personal attack.

Also I did NOT use that "smiley" in the sentence you quoted.

Sorry about the smiley accident. I honestly must have missed the last character in the quote of your message when removing the second half of the quote.

[Hudechrome]

I did a practical test today to assess this problem in working with photos, and I have to say it is a revelation. I opened a file, used "Convert to Smart Object" (quicker than crop or rotate) it to a specific image size like 36" then examined the deep grays. With a large black surface the pattern was obvious, but I seldom go that black. Where it became an issue is in densities represented in the bit dept between 2 and 10, especially around 8. I can see and print these values, (6 and above) and what I saw was a sort of fuzziness I've seen before when magnifying that went away when I flattened the image. I never went any further because the flattened image cleaned it up and I usually do the final inspection less than 100%. Of course, the print is always fine.

So, no damage done to the image itself but a certain uncertainty lingered around the degree of magnification. Was I going to far within the quality expectations I place on my large prints? No, but until now, I did not know why.

So, it's a good find, and I thank everyone for their contributions.

-Lawrence