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.

[Noel Carboni]

I did happen upon one other tidbit of information...

The "pattern" of visible transparency on the screen is ONLY visible to me if the layer with the minor transparency glitches is above nothing - i.e.,

It's the process that's trying to make the checkerboard show through that's in error.

It is NOT visible when rendering the layer with the slight transparency glitches above a solid layer (e.g., a solid fill layer).  It only becomes visible in this case with sets of extreme curve adjustment layers added over the top, at which point the color can be seen showing through.

-Noel

[Hudechrome]

I gave it a try and I can see it without any extreme adjustments like in curves. It's a slight brown patterning on the black.

Now this monitor has excellent black separation so maybe I can see it w/o extracting the pattern with curves.

Also, it's a function of the actual pixel density. I tried it with a 10,000x10,000 px dimension and I could not se it at any magnification. At 600%, I suddenly get a fly screen looking pattern that doesn't resolve by going to 8 bit. My first try was 200x200px., then 10,000x10,000.

I also tried it with Graphics Processor disabled, and no patterns showed up.200x200px.

I don't understand from where Chris is coming. There is no transparency layer when I create the test object.

[erickellerman]

I'm making a new file, 800x800, 16-bit, transparent, filling it with black and rotating with the crop tool. The GP is enabled. Bingo! Suit patterns! Disable the GP, try again, suit patterns gone.

[Hudechrome]

Update:

If I perform the test with Delete Cropped Pixels checked, I do not see the suit patterns, or any other.

[erickellerman]

No, Noel. No updates! My strong feeling is that the Graphics Processor is involved, as if I have it switched off, even my own psd file looks clean.

[Noel Carboni]

I probably made a mistake the first time somehow in processing the image.  Here's what I see.  The curves layers are as extreme as they can be.  Looks like maybe a 1 or 2 level error in the 16 bit data.

-Noel

[Chris Cox]

And that's exactly what I'm seeing.

The file is already dirty because of those artifacts in the transparency channel.

Something happened to the file before we saw it to cause the artifacts.

[erickellerman]

I see. But still, if my file is 'dirty' before it go to you two, how come I can clean it myself if I view it with the GP turned off in Prefs? Or convert to 8 or 32-bit. Or save it to jpeg?

[Noel Carboni]

Eric, normally you would not expect to see a 1 or 2 level (out of 32768) transparency difference on-screen.  I suspect your particular drivers are showing that where others are not because of an error unrelated to the transparency channel glitches.

There are just bugs all over this windshield! 

-Noel

[Noel Carboni]

Here's a weird thing:  I just opened the file http://www.erickellermanphotography.com/pattern.psd on my PC in Photoshop CS6 and it is perfectly black.

I even added two extreme curves adjustment layers above the background.  There is no pattern there.

-Noel

[Noel Carboni]

13.0.1 Update

I cannot reproduce this problem with the 13.0.1 code and ATI Catalyst 12.8.  I'm wanting to call it fixed in all facets.

Anyone else care to try?

-Noel

Message was edited by: PECourtejoie

[erickellerman]

I'm a Mac user, so I am testing 13.0.1 under different circumstances than yours, Noel. I report no change. The suit patterns are still there.

[Noel Carboni]

Just to be clear, the patterns you saw were getting generated into the files you were saving.  Have you recreated them from what should be smooth data using only 13.0.1?

-Noel

[Noel Carboni]

Never mind, motivated by your response I went back to trying it again.

I managed to reproduce it with 13.0.1.  I don't know what I missed or did wrong before.

Please scratch what I said in post 81 above.

Apparently the problem still exists.  But now I can create it using simple Bicubic resampling. 

-Noel

[conroy]

Noel Carboni wrote:

Apparently the problem still exists.  But now I can create it using simple Bicubic resampling. 

Noel, closely check CS5.1 again to see that regular Bicubic had the problem, anyway. A specific example is resize 256 x 256 to 400 x 400.

[Hudechrome]

I see nothing using resampling.

[conroy]

Hudechrome wrote:

I see nothing using resampling.

Here are example screenshots:

1. The original document is 256 x 256 pixels, 16 bpc, Adobe RGB 1998. The one black layer (there is no Background layer) cannot be distinguished from the black window background.

2. The document is "Bicubic" resampled to 400 x 400 pixels. A network of horizontal and vertical lines where the transparency grid wrongly shows is barely visible.

3. Photoshop displaying screenshot 2 with a region given an exposure enhancement in case anyone's monitor or vision is preventing perception of the lines in screenshot 2.

[Hudechrome]

OK, I simply used Background. Changing it to a Layer (Layer0) I can reproduce it except Exposure does not enhance the image. No change. But, if you change from 16 bit to 32 bit the lines disappear.

[conroy]

Hudechrome wrote:

OK, I simply used Background. Changing it to a Layer (Layer0) I can reproduce it ...

Yes, I suspected that you were using Background and that's why I made a point of stating that there was no Background layer in my example. Background never has any transparency and so it will always block the transparency grid (gray and white checkered display by default) from being visible.

... except Exposure does not enhance the image. No change.

My third screenshot showed an exposure increase being applied to the second screenshot. The exposure adjustment was not being applied in the actual document with the resampled layer.

But, if you change from 16 bit to 32 bit the lines disappear.

If I change mode from 16-bit to 32-bit mode, the lines become feinter but they definitely do not completely disappear on my monitor.

.

[Hudechrome]

I suspect these are artifacts and not real. Passing the eyedropper over the image showed no change from 0,0,0. So I built a grid and set it's values to L=10,a=0,b=0. It looked quite close in values to the grid generated with the upsampling. Again, the eyedropper show no change in the values as you pass over the grid. Of course, the grid doesn't print with the image if it is left on when printing so I would suspect this also may be true of these artifacts.

Inasmuch as image pixel size with which I generally work is way larger than 256 or even 400 px, and inasmuch as I see no evidence of this type of grid on a 50M image at 100%, it seems moot to me. It became of interest when I saw that the effect shows up when the Background is changed to Layer 0, and layer 0 is what happens to the background if you uncheck "Delete Cropped Pixels", of course I am interested.

So, hopefully this won't actually be a problem with real world image sizes, and if it does, I'll flatten everything before final output and save it as a flattened version.

Lawrence

[conroy]

There's an explanation for this display problem in the thread. It appears that some GPUs are incorrectly blending the transparency grid with pixels which have a transparency of a tiny fraction of one percent. These pixels really should not have any transparency but tiny transparency errors are arising in bicubic resampling. The transparency is so minuscule that it shouldn't be visibly different to full opacity. The problematic GPUs are erroneously hugely magnifying these minuscule transparencies when calculating the display for your monitor.

The RGB values of pixels in the resampled layer will not reveal anything. A pixel's RGB value is independant of its transparency.

Don't worry about your documents. They will be OK.

[Hudechrome]

Yes, I saw the explanation, and I wanted to check it out for myself, especially as to whether they make a real world difference especially in the darker values, which tend to more noise problems.

I never take anyone's advice about what may happen to my docs. I'll make every effort to check it out myself. One learns much in doing so!

Thanks for the feedback.

[Noel Carboni]

Summarizing, there seem to be two problems:

1.  Some resampling operations are leaving the transparency for a given layer at a value of something less than fully opaque.  A few levels out of 32769.

2.  Some video cards / display drivers are making that (barely) visible.  A few levels out of 256.

It probably all boils down to roundoff error at two different stages, one with the 16 bit math and one with the 8 bit math used to combine things for display.

I should have thought that Photoshop would have best-in-show algorithms internally that don't do this, and in fact it used to be true.  What's amazing to me is that Adobe didn't see fit to fix either of these issues in 13.0.1.

-Noel

[Hudechrome]

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

More to the point, these errors contaminate the 16 bit presentations, not 8 nor 32. So it isn't simply changing afterwards,  starting with either 8 or 32 bit excludes the contamination. Further, this action is unidirectional, that is reducing the size does not produce the artifact. But increasing it back to the original does produce it. Also, if the multiplier is a whole number, (2x, 3x, etc) the effect isn't present.

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. Magnify to 66+% and there is the pattern.

So it is insidious! looking at sharpening artifacts when checking at 100% after a  size increase other than a whole number will show up, and possibly confuse the judgement of, artifacts in shadows.

Proceed to go nuts trying to correct it!

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.

[erickellerman]

As the OP of this thread, I'd like to know if the gentleman's suit patternings show up in prints.

Has anyone tried?