png transparent layout objects

[comment]

I am not joking, but I am raising an eyebrow at some of your statements. And I am not about to enter a contest of 'who knows more'. This comes not out of arogance, but out of total lack of interest in such matters. When I said I didn't understand what you said, I meant precisely that. Your use of technical terms is mostly unfamiliar to me, in spite of being quite familiar with the terms themselves.

AFAICT, the only issue here is the incorrect rendering of a png file with transparency, placed into a FM layout, on the Windows platform. I don't know what native Filemaker objects have to do with this. Native Filemaker objects have no transparency at all, so if you hear someone talking about "creating native Filemaker objects for gradient transparency", safely ignore them. I'd be very surprised to learn that Matt Petrowsky said anything like that, and I fear you might be doing him grave injustice by suggesting that he did so.

Let me also put another issue aside, and that is the difference between the size of an object on one hand, and the size of what you call "the frame". A 1x1 pixel object is always 1x1 in Filemaker. But that object is on a plane of its own. This enables Filemaker to move the object, if required, to another location or backward/forward on the z axis. So a FM layout is not a single flat plane, but multiple planes layered one on top of another.

However, the display has only a single plane, so before a layout can be displayed, the various planes need to be married together. Also, native FM objects are vetor-based (they can be resized with no loss of quality), so these need to be rasterized (mapped to pixels).

Now, it is quite common, when rendering layers into a flat bit-map image, to apply anti-aliasing to the edges of objects. This is creating an optical illusion that minimises the 'stair-case' effect on round or slanted edges. So when you look at the rendered flat image, be it on screen, or in the buffer of a graphic card, the object may seem to have grown in size, as the result of fuzzy edges. Different applications may apply different amounts of anti-aliasing (and different algorithms), so it is not surprising if you've noticed a difference in the results.

I have reasons to believe the Filemaker farms out the entire rendering process to the OS, rather than performing it "in-house". Since I don't have access to the FM application code, I cannot be sure, but various indications point to this (LaRetta's dancing phone being one of them).

So what it basically comes down to is that Windows does a very poor job of it, both in interpolating the transparency values over the stretched image, and in anti-aliasing its edges. IIUC, there is no problem if the image is not enlarged, so the concusion seems to be not to stretch png images in Windows.

[comment]

Well, so much for being concise...

[Inky Phil]

Just for the record I need the forum.

Without this forum and the cafe I could not have achieved what I have and I am truly grateful.

As in all walks of life the folks around these places are as varied as they are many but they all have one thing in common - a readiness to share, which is a quality in ever decreasing evidence in modern society.

I find the world a better place for that.

Phil

Edited February 16, 2006 by Guest
should have been in reply to KMHAPPEL

[kmhappel]

Hmmm. Comment, the problem is NOT simply the incorrect rendering of png files placed in a FM layout on the windows platform, NOR that the observed extra pixels that occur in FileMaker objects are being caused by anti-aliasing during rasterization although it may contribute NOR solely a windows rendering problem ( as horrible as it may be ).

(1) the gradient objects that are included in the Theme Library are described by Matt P. as having been imported through the means of a png file. These objects have embedded in them vector controls for radial gradients which, if they were reduced to simple pixel patches by the process of being formatted by Photoshop as png files, could not occur or be reintroduced;

(2) the effects can also be caused by objects that have never been in a png file such as FM graphics objects;

(3) if anti-aliasing is causing the extra pixels, there is still an unexplained issue. Anti-aliasing processes normally produce interpolated color values that define opaque pixel colors, not transparency masks, So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information. Alpha channel information is organized on programming abstraction levels well above the operating system, BTW so are the layers.

(4) If the problem is a Windows issue alone, then it would seem reasonable that the problem would be invocable across a wide number of programs, yet it is not a widely known phenomenon.

(5) object layering is defined well above the operating system or card driver, the grouping and assignment is probably a pure FM process. It maybe using a standard intermediate code library such as Quicktime or x-code on the Mac.

(6) The stretch breakdown is not just oriented to the right but towards the right and towards the bottom regardless of the options set in the reduce and enlarge options ( such as center-center or bottom-right ) but only when the object is close to one pixel by one pixel in size. This is certainly not an attribute of Windows.

(7) The png file created in a graphics program whose content is a single pixel definition, may be inserted by FileMaker as a pixel patch that not a single pixel. This is clearly a problem between implementations of the PNG standard in various programs;

(8) the problem is mentioned as not existing in extension, its reduction rather than extension and, more correctly, if the pixel patch is equal or greater in size to the display frame. Even more important is that under reduce or enlarge, and

(9) the right-bottom transparent edge gradient effect has been able to be recreated in Mac versions of FM.

For the rest, if I am wrong I apologize. I will lighten up. And it is very clear to me, Inky, that I also need help with filemaker and I also am very glad and grateful for assistance that addresses my problems.

As for raised eyebrows, well...

[comment]

the gradient objects ... having been imported through the means of a png file. These objects have embedded in them vector controls for radial gradients

No. I'm afraid you're repeating the same mistake. There are no vectors in a png file.

the effects can also be caused by objects that have never been in a png file such as FM graphics objects

Anything is possible, but I see nothing that would point to such possibility (see Occam's razor).

Anti-aliasing processes normally produce interpolated color values that define opaque pixel colors, not transparency masks, So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information.

The pixel information *is* both color AND transparency. When two (or more) pixels occupy the same position (layers), the rendering engine needs to decide what the color of the final pixel should be. This decision is based on the pixels' color, their transparency, and layer stacking order (front/back). For anti-aliasing, the information from surrounding pixels is also considered. Needles to say, when rendering for screen, the resulting pixel is fully opaque.

So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information.

See above - the rendering mechanism sees pixel information as BOTH color AND transparency.

Alpha channel information is organized on programming abstraction levels well above the operating system, BTW so are the layers.

Here's an example of sentence that to me carries no meaning. Alpha channel information is written in the png file as a number between 0 and 255, per pixel. A fully red, half-transparent pixel is an array of {255 ; 0 ; 0 ; 128 }. I see no abstraction here.

If the problem is a Windows issue alone, then it would seem reasonable that the problem would be invocable across a wide number of programs, yet it is not a widely known phenomenon.

That is a good point. OTOH, if it is Filemaker, why doesn't it happen on OS X?

Fact is, I have no way of knowing whose fault it is - I can only surmise. Let FMI and Microsoft work it out between them.

Meanwhile, I googled for "+png +Windows +transparency +problem" and got 347,000 hits - so maybe it's not such a good point after all.

[kmhappel]

I'm afraid I can't quite fathom how your 1-pixel transparencies work either.

I would suggest that you make some one pixel rectangles in a windows version and insert them into container fields and watch what happens. I don't know how they work either, but they do occur.

Edited February 18, 2006 by Guest

[kmhappel]

Comment, doing the equivalent of yelling doesn't change the basic fact, that what you have to say doesn't address or solve the problem at hand. Putting it on me doesn't help either.

A lot of other people that build graphically complex interfaces to FileMaker databases that are used over networks and the Internet by lots of users concurrently need tools like the ones offered in Theme Library and will run into the problems I have and so I request, [color:red] please stop the rant and be part of a solution.

Edited February 19, 2006 by Guest

[kmhappel]

Because of the question about what Matt Petrowski may have said, I transcribed the text of his comments that have been important to me (the urls are included so that anyone can listen to them themselves).

[color:blue]I bought the Scriptology Theme Library because all the other Scriptology products I have bought have been well worth their price and because the Theme Library in its " Theme Library Overview Movie, http: // www.scriptology.com/index.php?product=theme_library, says

"…when you get to all your gradients, all of these have been have been optimized for FileMaker Pro meaning they're [color:blue]native to FileMaker Pro. They'll refresh really quickly and they'll work really fast over the network especially if you are working with the database over the Internet using FileMaker Pro."

I build databases and data mining tools for people who make decisions based on their perceptions of data states and the relationships of those states to actions they need to take in business. This often means that the interface is as important, if not more important than the data. The interface actually embodies and reveals any value that that is present in the data, and without it the fact of having data is just a cost. Because FileMaker has such a great GUI building toolset I have long used it for prototypes, and with version seven I began to sell projects with it as the final target environment. One problem that constantly comes up is the bandwidth required in networked versions to just move the interface among the users who are constantly interacting with a dynamic data state causing changes in the GUI configuration that need to be displayed. So I was very interested in the Theme Library.

Having received it, [color:blue]Matt Petrowski's Scriptology Theme Library was indeed a GREAT PRODUCT and well worth its price. It had impressive gradients that inspired me to include them in a product that I am building under contract and that work is paying my bills, such as they are. During the use of the Theme Library I began to investigate the different behaviors that the transparency gradients had. I found this movie at FileMaker magazine: http://previews.filemakermagazine.com/videos/599/ThemeListLayout_full.mov "A Layout Designer's Tips and Tricks" It, in turn described how he had made the transparency gradients

"There is only one other thing that I'd like to show you before we finish up. And that is, with regards to a question that was asked about the Theme Library and in particular using transparencies and how you would use those... starting with FileMaker 7 transparencies were supported in the form of the PNG support that's added into FileMaker 7 and now FileMaker 8. PNG supports alpha channels and different levels of transparency, however there is one problem, and according to what I know FileMaker is using the QuickTime library, I know that it is on the Macintosh, but while FileMaker doesn't necessarily install QuickTime I don’t know whether its embedded into the FileMaker application on Windows or what the developers have done but things don’t work the same way on the Macintosh that they do on Windows. Although on windows you do get some nice effects. What transparencies are for and the reason that they're single pixel lines, at least they are for the gradient transparencies and the solid transparencies, are these are PNGs that have been inserted into the FileMaker Theme, ah, Scriptology Theme Library and when you go into layout mode, all you have to do is choose one of the transparencies that you want to use. Lets say for example 50%... you can use this either in a container field or you can use this straight on your own layout...

As I scroll this down you will notice that on windows when you drag out the solid transparencies that go from a solid color down to a lighter color, they will fade or they will blur out as you drag them out. So if I drag this all the way over you can see that the blurring or the blow out or the fade out is going to be much stronger rather than a nice crisp edge which it's supposed to be. On Macintosh this crisp edge is still crisp but on windows it blows out. When you take a look at the transparencies over on the gradient transparencies, and I'll select 30% or 40% copy that ... when I resize this, what you're going to notice ... is rather than a continuous tone that the transparency is supposed to be and will be on the Macintosh I get more of a arc or a circular, actually its a quarter of a circular look when I use this transparency. Now that's just something that's weird that is going on even though this was created as a solid transparency. But I wanted to show you how I created these in Photoshop, its how I created the transparencies for this windows XP theme and many of the other transparencies that are used in the Theme Library...

( He then describes how he creates a “1 x n” pixel array in Photoshop )

The reason is that one pixel, the amount of information is going to be very small and in FileMaker you can drag this out to any size that you need and FileMaker will scale that transparency and it will make the transparency work for the whole layout. The one issue you need to be aware of is, if you have a transparency and you drag this out to the full height of the layout you're going to get layout refresh issues... so the best use of transparencies are typically going to be smaller." ( He then describes how he creates an “m x n” pixel array in Photoshop and explains that this will then cause you to "suffer a bit larger file size" when using “m x n” pixel patches ).

http://www.fmforums.com/forum/attachment.php?attid/6467/

http://www.fmforums.com/forum/attachment.php?attid/6468/

So I opened up my copies of Photoshop, Illustrator and Canvas and discovered that none of them would export a PNG file that FileMaker would import in the way that Matt had described, that is, with a transparent background. I assumed that there was something I didn't do correctly and began to search the Forum using keywords like transparency. I browsed or read every thread on the ten or twelve pages of references that the search brought up. But none of what was offered worked with my programs. So I created this topic.

This still didn’t solve why the objects reported by Petrowski as PNG file imported had vector control components stored in them. [color:blue] Why didn’t I just stop thinking about the subject because it had been said that PNG files do not have vector information? First of all, I have no reason to mistrust Mr. Petrowski as everything I have ever bought from him has worked wonderfully. Second, because Sherlock Holmes once said (ah yes, from the favorite quotes department LaRetta, “when the evidence doesn’t fit the theory, don’t change the evidence” and the object in the Theme Library does have a vector control. Secondly, because I discovered that complete and compliant PNG implementations are anything but normal and the chances are very high that FileMaker has used non-equivalent implementations of PNG and other graphics processes in its two versions.

[color:black]The answer to the original question is: [color:red] Each graphics program has to be individually tested for the way that it creates PNG files and the way those files are imported into FileMaker. Pasting artwork into a container field and rotating it may not work but it is a thing to try. A number of programs work such as OmniGraffle4Pro and Photoshop. However, a current version of Photoshop is required and then only when the 24bit PNG option and the transparency options selected before saving the file for web use. Canvas cannot be used. PNG capabilities in applications have a huge history of bad, incorrect or partial implementations and that there are hundreds of thousands of references to problems with PNG files, transparency, Windows Internet Explorer; there were several hundred that talked about Photoshop and other graphics programs and PNG files. The revision of Photoshop I was using was one of those that did not support transparency in PNG files and that only the most recent revision does support full alpha channel transparency and then only if the “24bit PNG” and “transparency” options are selected. I had also emailed Canvas and they replied that Canvas did not and does not support writing transparency into PNG files even though it says it supports the file standard. BTW non of the references I saw described the FileMaker display issues.