Pixelmator previews don't show correct results. Why?
 

Been using Pixelmator for over a year now, mostly with fabulous results. It's a great work flow well thought out but I noticed something extremely alarming yesterday:

On any image displaying less than 100%, things like Levels, the preview will be vastly different from what you see after you hit the "OK" button. Not a little different, but VASTLY different.

Someone on the pixelmator team says it's impossible for any graphics app not to do this..that you must be at 100% for the filters to look the same in preview as after hitting the "OK" button.

I've been doing this kind of work for 25 years and I know that this statement is factually incorrect. For grins I tried it in Photoshop, Gimp, iPhoto, and in all 3 the preview is exactly the same as the result after hitting the "OK" button.

Can anyone here think of why the pixelmator team would have this position? To me a graphics program that doesn't accurately display results in preview is like shooting blind, or like having a screen door on a submarine..

Thanks for any thoughts..I'm thoroughly bamboozled by this.

a

Screen captures of what you are seeing (previews and final results) would be useful.
Otherwise it's hard for us to understand what you are seeing.

So true...here is a 5-second clip of the Levels reversal happening as I do it. Look at the type on that page..my goal was to darken it to make easier to read..you see the type darken, then after I hit "OK" the type reverts to it's previous lightness..perhaps not all the way, but it shouldn't revert at all.

thanks for watching...should be in video stores soon!

http://coffeeonmars.com/screenshots/levelReverses.mov

for some reason my link isn't appearing but ^^ there it is.

a

http://coffeeonmars.com/screenshots/levelReverses.mov

So, if what you say is actually happening, then what is the result when you _decrease the grey level, then hit OK? Does it re-darken near original, or does it go even less grey?

No..the grays stay put if I move that slider to the left/lower/lighter, but if I adjust the white end to the left/lower/lighter, that goes back to what it had been before the slider adjustment.

I took a screen capture of your movie and opened the PNG file in Pixelmator (3.2) and brought up the Levels tool.
When I move the slider and press OK, I get almost exactly what is shown in the preview.

Could the problem be related to the format of your image? Or a layer?

Sure..I've thought of that but I don't see what aspect of that image it could be..the problem. same thing doesn't happen with other images. and I've tried a variety of formats: pxm (pixelmator-native) tiff and png to see if that would matter..it appears not to.

one thing I've noticed is that if I make a text document, to sort of mimick that scanned page, PDF that then open it with Pixelmator, save as a tif or png, I can reproduce this problem. that document is no longer text, per se, but has the same tonality as a text document.

but why would that matter? "Levels" is a tool that adjusts black, gray and white levels, then after you hit OK, the app should apply that adjustment..the entire point of having a preview is to show you what your adjustment will look like after you hit OK..why would it change - even slightly - after hitting OK?

also, I get my weird result on 2 different macs: 2009 mac pro on mt lion, and a 2010 Mac book pro running mavericks, and the newer, mavericks-only pixelmator.

shouldn't performance of software tools be nearly identical across Macs that can support said software?...Owing to the consistency with which Macs are designed and manufactured?

I mean, it's not like I bought my Macs out of the back of a pick up truck from some guy who makes homebrew Macs out of junk parts..

OK..I am told by Pixelmator devs that this is a function of OpenCL which gives "blazing performance" but sometimes delivers incorrect results like the one I'm talking about in this thread.

I'm a bit speechless but I guess this is the technology used..

Here is a reply, straight from the Pixelmator team:

I believe he meant "high contrast" where he said "high pixel density."

What I get from this is high-contrast images are more susceptible to the reverting levels adjustment than images containing more even tonality.

I don't know doodly about OpenCL (or OpenGL)..I merely know *of* them..don't know enough to understand why these things happen, or what to do to ensure that I get what I'm after, consistently.

I guess there are numerous ways of churning computer data and some ways have downsides?

One might want to encourage them to implement a perhaps less "blazingly performant", yet working alternative while they wait for an upstream fix.

That way the user could decide about his priorities in the Prefs.

Yeah, that's a good idea..I'd thought about that.

Not sure how committed they are to OpenCL or if a change in technology means ripping out all the wires, so to speak, and starting all over...

It seems not the best move to release something like this having such important misses...I can't imagine a client accepting the OpenCL argument when looking at poorly adjusted images they paid to have adjusted correctly..

to me, this seems pretty basic.

This is a misunderstanding on the part of the person who told you this. OpenCL can certainly be fast. But it does not inherently deliver incorrect results. Bugs in code deliver incorrect results.

That the bugs were somewhere in code making use of OpenCL, or even that the bugs might be somewhere in the code implementing OpenCL, does not mean that OpenCL is inherently delivering incorrect results.

Trevor

OK...what do you suggest as the most diplomatic way of suggesting that they explore this angle which you bring up?

a

It seems (from what you have said above) that you have reported the bug to the developer and they have investigated and understand it.
I don't think anymore is needed in terms of communicating with the developer.

It would seem that the bug is that the preview (calculated in a fast way, presumably using "OpenCL") does not accurately reflect what the final effect will be.
I'm sure that the developer will be trying to fix this bug now that it has been brought to their attention. But of course, developers always have more to do than there is time for - and so if this bug only occurs in certain unusual circumstances, they may not assign it a high priority.

yeah they have said to the effect that they know about it but sound resigned to its current failings..

well..the sun won't explode...

It might be helpful to raise the priority of the bug by checking whether there are already similar reports in their very own forum:

http://support.pixelmator.com/viewforum.php?f=5

Anyway, you should not hesitate to post your very detailed bug report there as well.

It would probably not hurt either to link to this thread.

That way, not only the techies, but also whoever is in charge of PR might be tempted to speed things up for a fix or a workaround to end the public embarrassment.

It could be as cheap as a secret feature in the apps Settings-plist such as UseBlazinglyFastButSloppyOpenCL that you could set to false via the defaults command.
No UI clutter, but whoever is annoyed by this (and from cursory reading of the forum it looks like you're not alone) gets to chose. And pixelmator gets a handy extra option while debugging a users situation.

Very nicely stated, voldenuit..it could be a win-win all around...thank you!

It would be useful (for this thread, and for the support forum) if you supplied a test image file that exhibits the problem. And describe precisely the steps needed to show the problem.
E.g. you intimated above that the problem has something to do with 100% of the image not being shown (?), so explain what the necessary steps are to get to the state where the problem is exhibited.

Sure.

I saw the problem first with some scans of text I was adjusting to improve readability. All of the pages were made better by moving the middle (grays) slider to the right to 65; until you see the number "65" the "grays" number field.

I noticed that while the preview looked the way I wanted, the image appeared to "revert" after I hit "OK."

Here's the procedure:
Wondering whether there was something peculiar to the scanned image, I whipped up a simple document full of lorem ipsum in Text Edit and saved that as a PDF, then opened in pixelmator. Text now on 1 layer I reduced it's opacity over white to try to imitate the scanned pages whose type was also "weak" ie not fully black and contrasty for comfy reading.

So, you'll have text on 1 layer. Make a new layer full of white below the text layer. reduce opacity of text layer so that it's maybe a 50% gray, flatten this image, then pull up layers and boost the middle (grays) slider to 65. Observe the effect on the type. Get it to a darkness you think facilitates comfortable reading. for me, it was 65 for the gray slider.

Now hit the OK button.

You will/should see the change you just made and approved in Layers revert to the previous washed-out type you had before adjusting the levels.

the bit about the 100% zoom level I believe may have been a bit of a language issue. I think the person who responded from Pixelmator said that for any effect Final to match what you saw in Preview (while adjusting) had to be at 100% zoom. So, this means you couldn't view all and make your adjustment. The reason given:

reason I think possible language problem is that this explanation doesn't sound credible to me, so I think it's possible the person misunderstood my issue to begin with.

thanks for reading!

Please attach the sample document on this thread by using the Manage Attachments button that is at the bottom when you reply.
Attach the document in the state just before the problem occurs so that the procedure to reproduce the problem is simpler:
1) open document
2) use Levels control to change the level
3) press OK and compare to image shown in preview.
(Assuming the above is a semblance of the procedure)

My 2 cents, with respect: I feel that what is important to understand here is that this problem is not peculiar to just 1 file, or to just files made by me, but occurs across files which have certain characteristics, namely: high contrast, such as black/gray text on a white background. Since anyone can find themselves needing to adjust levels on a high-contrast document, this problem affects the entire Pixelmator user base.

Thank you!

a

Understood.
But to make it easy for someone else to reproduce the problem, please attach one example file where the problem occurs.

(As I said above, my 10 second attempt at reproducing the problem with a screen capture from your movie did not show the problem with my Pixelmator. And I don't want to spend much more time than that on trying to reproduce the problem - so make it easy for me (and others).)

Right. I get the concept. Make it easy for others to repeat my steps. However, please understand that it's not just this one example test document that's of concern. It's the documents and images of other people, out there in graphics land, who might say, "Hey, I just OK'd the levels adjustment and Pixelmator un-did it!"

Test document attached, per your request.

Well, thanks to file size limitations, I can not upload my test document.

to make it small enough file size, you can not observe the problem on that small a size image.

any suggestions to make this easy on me?

Dropbox ?
Or other external storage which you can give us a URL to.

The fact that the problem only occurs on larger documents is itself of interest.

yes, it is.

OK..I'll try it tomorrow