Adjustment layer effect changes appearance when rasterizing or grouping

[NotMyFault]

The rendering difference comes again from mipmaps rendering, and you file containing specific features who amplify issues:

• layer fx on image/pixel layers with semi-transparency 

I filed a feature request long ago to at least offer a (slow) accurate preview mode. You may add your vote.

 

[NotMyFault]

Just try this old test image. It shows red color where no red is present depending on zoom level

rendering bug at 100% rasterized blend rangeafphoto.afphoto

 

[CM0]

Thank you for the reference. I suggested exactly what you stated earlier in this thread. We need at least a preview mode for accurate rendering.

Unfortunately, there a lot of such issues that don't get the priority they deserve as they are so poorly understood. Many likely have encountered such problems, don't know how to describe it and goes without being reported or it is diluted by being reported under what would seem unrelated topics such as how this thread started.

[CM0]

@Chris B Could we please get a proper issue logged with development? It seems as @NotMyFault has pointed out, this has been an issue reported by many people, but likely confusingly miscategorised. 

Please take note of this comment on a previous post -

This thread in the above issue indicates that it is impactful to many people and likely contributes to lots of miscategorised issues/bugs.

The previous issue has been tagged feedback for v1 so probably is not getting the focus and priority that it needs. If we could get focus on this better described problem, then we can close or consolidate proper notes into one issue to log with developers.

[Chris B]

18 hours ago, CM0 said:

 Could we please get a proper issue logged with development?

Hey CM0,

As previously explained, viewing the document at 100% will give the same results as viewing the exported copy.

Left is a PNG and the right is your afphoto file viewed at 100%

There is no bug here. It's the way our renderer works with live filters/adjustments/FX.

NotMyFault has already logged the request which has not been picked up by the developers.

[CM0]

4 hours ago, Chris B said:

Hey CM0,

As previously explained, viewing the document at 100% will give the same results as viewing the exported copy.

 

There is no bug here. It's the way our renderer works with live filters/adjustments/FX.

NotMyFault has already logged the request which has not been picked up by the developers.

Also as previously explained this is not a work around. There is no reality in which the UI lies to the user that is desirable or would not be seen as a bug to users. I understand this is by design, but it is severely impactful in a negative way to our work and dismissing its importance that it is by design is extraordinary frustrating to users.

Previously you had expressed interest in solving this issue and I appreciated that interest.

Exactly how does a request ever get picked up by developers? That request has indicated it is impactful to many users. Has this been logged for development into their tracking system? Often we are told development will take a look at certain issues, is development even aware of this discussion?

[Chris B]

Hey, sorry, please let me try and explain... Tech and QA (who generally reply to the forums) log bugs against the software with the developers. We do not generally have a method of reporting features other than this forum here which the developers read:
https://forum.affinity.serif.com/index.php?/forum/122-feedback-for-the-affinity-v2-suite-of-products/

We can, and do, log feature improvements for things but this is generally on a smaller scale. As an example, we could log 'The brush size slider increments from 1px to 100px too slow, please accelerate it'. Unrelated to your issue, but an example of what we do log.

What we are talking about here is a complete overhaul of the renderer or a new view mode. This is what I assume NotMyFault was requesting with the 'True accurate preview for Photo' feature.

I had already linked this thread to an existing issue that is related to mipmaps and viewing the document at 100%. I was unsure whether to tag this thread with that report number as it's not quite the same but its fix would achieve the same result as what you are requesting.

[CM0]

Thank you. Let me just clarify what I would hope could happen in this case. This issue, as seen by Affinity, is not a bug; however, it is also not a "nice to have" as seen by users as it is an issue that is breaking the user experience. Behavior that is misleading in a way that some could say is displaying wrong or incorrect information. Any user who experiences this will immediately think "bug" or something is broken.

To simply categorize or place it alongside all the other new feature requests seems out of place. 

19 minutes ago, Chris B said:

What we are talking about here is a complete overhaul of the renderer or a new view mode

So yes, if features aren't tracked, then developers simply browse features as they have time, which I'm certain is extremely limited. This request was likely long forgotten with its importance to users. I am fine with letting the developers come up with a solution. Overhaul, new view mode or something else etc. 

Suggestion:

I suppose a suggestion for Affinity to please consider would be a new tag for some features that are in the classification of "breaking user experiences" or "unexpected behaviors". I think this might be the optimal middle ground as it allows developers to find and consider such issues and prioritize them separately from the "nice to have" new features. This way, as a user, I would at least feel that the information I have delivered has been correctly understood as to its implications whether it is ever implemented or not :-)

[Chris B]

I understand what you have said. All of this feedback will now be viewed once someone assigns the ticket and looks at the linked threads.

For what it's worth, I would also prefer to not have to view my project at 100% or do a merge etc. I was impressed with what I saw in Krita with its live filters and I would hope that one day we could implement something similar  

[debraspicher]

I agree 100% with @CM0. This is not good implementation and I hope, that like with other features that have been added and are being worked on, that further work can and will be done to fully realize the potential of these features. I understand there are technical limitations, but it should not be the deciding factor behind any design decision where user experience is concerned.