I'm using PSP 7 (I know it's old, but it serves my purposes).

I am resizing a bunch of images. PNG images with alpha transparency load with black backgrounds when I first open them. I have little experience with masks. I learned that I can do Masks > Load From Alpha Channel to see the transparent areas.

After loading the alpha channel, I resize the image. Usually, this works fine. However, sometimes the edges look a bit gray - kind of like if I made a transparent GIF on a gray background.

For the record, the box for Resize all layers is checked. If I uncheck that, the edges are black after resize. Also, the original images are already PNG-24 (16 million colors).

Here is the original viewed at 8x zoom (scaled in the browser to fit):



And here it is after reszing viewed at 8x zoom:



And here is the resized image viewed at 1x zoom:



It's probably not that noticeable to a lot of people, but the top edge does not look smooth to me.

Is there an easy way to fix this? Do I need to resize the mask separately?

The last one I had like this was a white circle. So I just cropped out the edges and added a white circle behind it. This one is a little harder.


Question: Control Fields vs Heap "Mock" Fields for Branching Trigger Behavior
Answer: Good quesiton, but what is the real question? The key phrase from your question for me is 'business process triggers'. If I may, I think the discussion needs to start from a application layering perspective, or put more specifically 'where do we put our business process logic?'. Before I get on to that let me say this about triggers...

The thing about triggers is... they respond to data centric actions, period. If you view the top to bottom architecture of your Force.com application, its easy to forget your still dealing with the database tier when writing code at the trigger level. If you look at the rich level of API support and an native UI around this database tier. You will soon realise your effectively developing an app on a database schema that is by default open, like it or not. You have to service this way of interacting with your app. Take Salesforce Touch for example, this provides your clients a rich mobile/tablet client for free! Then the new REST API, the list goes on. You only get the benefit of these if you embrace letting your customers / developers access this tier safely and clearly (so good database design is even more important ironically). So when you look at it from this angle, its important to consider carefully any requirements that lead to design patterns, validation rules etc that might impact the use of your 'open database tier'. And don't get me wrong, there are some good reasons to, but you must design firstly for things to be open and discuss carefully what the implications are of over complicating or closing off parts of your database schema interaction.

So that all sounds good, but why do I still find it hard sometimes to implement what I want? Well, if your application is typically "data centric" in its purpose, you'll generally have an easier job. A user interactions, much like Salesforce CRM, are typically tasks surrounding the scope and lifetime of individual records. So triggers, layouts, record types really start to come into their own here. But if you have an application that is in part 'data centric' (for standing / master data) and part 'process/task centric' where does that leave you? Enter SOA...

Service Orientated Architecture and Control Fields? Unless you're solely a data centric application. Your going to have to find a place for your clients (and by 'clients' I am not just talking about human consumers here) to consume / access your business process logic. Having them tweak Control Fields at your schema level may make sense and there is scope for it, if you can work it nicely into the schema. But over use of it, along with having your clients dependent on a deeper understanding of your schema. Will introduce voodoo into your schema and increase the barrier to entry for your application interactions, developer, end user or platform wise. So to avoid users poking around trying to reverse engineer your VF logic, control fields, why not consider exposing a service layer in your applications for such logic? 

So how do I do that then? REST has recently taken hold over Web Services, primarily because of the aforementioned 'barrier to entry'. It is easy to document and if done correctly is self describing, much like the 'data centric' aspects of your application utilising Custom Objects. So for business proceses, for me REST (I include JavaScript Remoting in this) gets my vote for exposing business process logic to your clients (be they human or machine). If you adhere strictly to this approach (which requires a SOA based design process for your app) then you'll end up with a rich set of API's for you and your clients to consume. Which in this day and age of Cloud computing is pretty much a must! So while you might argue this is not strictly SOA (as yes Salesforce does handle a lot of the mechanics with oAuth etc). I feel there is room for taking a SOA based design and architecture approach to designing Force.com applications.

So OK, how would I implement the code in the question above? Developing a generic Apex solution is really a solution for a problem that I don't think should be solved generically or at the Apex level (see my thoughts below). Generally to much of this approach is teaching your database tier code
about the business processes that should be implemented above it. You should let your business process tier do the driving and expose that as a service for your clients / callers to consume (in addition to those already provided by Salesforce btw!). The trick then is marketing and supporting the strict design, development and consumption internally (for your own client developers, be they VF, mobile or otherwise) and externally of them. Again don't get me wrong we should absolutely fill our triggers with great value add logic, but it should know its place.

Control Fields : Heap vs Custom Field : That said, when taking the Control Field approach, and as I describe above is valid, when it 'fits' with your schema and thus API / native UI experience sensibly. When implementing it I am in favour in the first instance of designing it in into the application schema as a field. This way everyone knows whats going on. Again the schema is open and not declaring it (by managing internally) only leads to frustration, low barrier to entry due to higher complexity (internally and externally). I've also been burnt a few times with Static, initialisation and state carry over, while I'm not 100% sure, for example, I think Batch Apex serialises statics over 'execute' invocations, which can catch you out at times.

Application Enterprise Patterns on Force.com

Here is a diagram i presented at a recent Dreamforce session about Enterprise Application patterns. The sessions slides takes a simple scenario and walks through, what might be described as a 'consolidated' or 'merged' approach typically seen when people start out or smaller applications, and again this approach has its place as well. What I followed this in my session with was a more layered approach using some Application Enterprise patterns along the way. I'm pleased to say it got quite a good reception and has since generated a steady stream of interest (I've got a draft blog posting on it in the working btw). You can find the Github repo here, with more info on the patterns. The slides are here.



NOTE: That Trigger invocation is not shown here, the SObjectDomain class takes care of routing the CRUD events from the triggers to the 'Domain' classes representing the Standard or Custom Object behaviour your application is implementing. This pattern enforces development of appropriate logic for this context. Leaving the Service layer to doing any process level orchestration.