Picture Differences Console vs Desktop due to AlphaChannel

Targets macOS
1

I found a difference in the HorizontalResolution doing the same open of an image in a console app vs a desktop app. Here is the code
Console:

dim f as FolderItem dim p as Picture f = new FolderItem("/Users/brandtjc/j.jpg",FolderItem.PathTypeShell) p = Picture.Open(f) Print ("Image Horizontal Resolution"+ p.HorizontalResolution.ToText)
reports the Resolution as 72
and on the desktop

dim f as FolderItem dim p as Picture f = new FolderItem("/Users/brandtjc/j.jpg",FolderItem.PathTypeShell) p = Picture.Open(f) MsgBox("Image Horizontal Resolution"+ p.HorizontalResolution.ToText)
Reports teh resolution as 97

I’ve inspected the image under Photoshop and the resolution is 96

If I run the code with an image which Photoshop shows as 72, then both report 72

In this case this forms part of a batch and a desktop solution to do similar, so I need to get the same result in both environments.

Is there a something I am missing

I am not sure how to upload a sample image here

2

Curious: Why?
In both environments you have the same number of pixels.
I think the difference between the console and desktop will relate to the fact that the console has no graphic interface… unless you choose to decide otherwise, everything is assumed 72dpi

Not sure why you see 97 in Desktop, mind you , but its the same picture.
What do you do with the resolution , and what problem does this cause?

3

If you say 96, my answer would be: Windows screen default resolution (on non HiDPI screens), but 97 ?

4

Does a normal picture always carry a specified resolution? In a standard jpeg header, the resolution info is simply the pixel size.
Usually, it is meant to draw one pixel per screen pixel. So it will be 72 dpi on a non-Retina Mac screen, 96 (97 must be a float inaccuracy) on Window, 144 on Retina Macs and so on.
Of course, its size will vary that way. The product of size and resolution will always stay the same.

Some image processors allow you to define the resolution to set a default value for the display size.

Did you inspect the image showing 96 in Photoshop on a Windows machine? Try it on a Mac and see if it will not report a different resolution because it has none attached to it. Or: have you tried to save it again from Photoshop, now with a specified resolution, and see what the Xojo apps report now?

5

Thanks for sharing ideas guys

@Jeff : Curios Why?

I apply certain logic and wanted to process a huge lot of files (couple of thousand at a time) and save the results in a batch process, and was thinking better to run that as a console. I actualy first pick up the difference when I applied the same process to both RGB surfaces (processing the pixels). So my online version picks up different results if processinn1 image at a time.

Here is the funny part:
I get the same width and height reported each time
my code which basically does an index of the colors of each pixel, using

myColor = image.RGBSurface.Pixel(x,y) dictionary.Value(myColor) = dictionary.Value(myColor) + 1
using exactly the same loop returned a different result set

This made me curious so I investigated and found this Horizontal Resolution to differ, and so far that was the only difference I could find. (see below for further differences found since)

@Ulrich: I am working on MAC (2010 MacBook Pro 17", NVIDIA GeForce GT 330M 512 MB, 1TB SSD, 2.66 GHz i7, 8GB RAM, El Capitan 10.11.1, XOJO 2015r4, PhotoShop CS5 12.0)
I tried saving from PhotoShop. The image size moved to 170KB from the 35KB before (for the test image), so clearly another compression setting used. (The actual images to be processed are 2500x2500). Results are the same. If you change the resoltion down to 72 it also changed the width and height down to 296 from 395. I did the etst again with the 72 Resolution, and both reported 72.

I can understand the 97 being some Float accuracy thing.

I also tried FolderItem.OpenAsPicture but exactly the same result. Saw this as an alternative to Picture.Open on http://flylib.com/books/…

This is really putting quite a stumbling block in the way of my thinking, but I am open to suggestion of how to consistently extract the RGB Pixel values from each pixel. Naturally I could code something around teh AlphaChannel and thereby adjust something, but I am not sure that would be a reliable approach.

I have now checked and found something else using the debugger in both cases:
(and on 72 and 97 Photoshop versions also)
On the console version it reports HasAlphaChannel as True and on the Desktop as False
Vertical Resolutions also as 72 and 97 respectively
Other properties the same
Depth = 32
ImageCount = 0
Objects = Nil
Transparent = 0
Type = Bitmap = 2

When you open up the Graphics portions there are also differences
(Console values first)
Bold = False vs True
TextAscent 14 vs 12
TextHeight 17 vs 15

Admittedly I am running under the debugger, but I was not expecting different results based on that

Would there be some logic in the library/class for Picture that takes into account console vs desktop?

Any other suggestions here?

6

to ME resolution is a function of width and height of the image (in pixels or points)
while density (or DPI) is more what you are describing… and for most things that is useless information, as the “Dots per inch” require somewith with consistent number of “pixels or points” per physical inch.
A printer will meet this criteria, althought the dots per inch is “adjustable”… 72dpi, 300dpi, 1200dpi depending on the printer
A monitor does NOT, as there is a fixed number of pixels per the width of the screen, so a 15" screen might be 1280x1024, but a 19" screen might be the same resolution.

Also, console vs desktop WILL provide different values for font metrics (see my conversations on this forum about PDF generation). The font metrics between OSX desktop and Windows desktop for the same font vary significantly as well.

So to answer your question

No… and trust me, I have wracked my brains for months trying to get my PDF class to work consistently across platforms for this very reason.

7

Thanks all for the inputs.

@Dave: Thanks for the dpi explanation, and actually the pointer that as far as the screen and image goes, this should have no bearing.

I’ve looked into it, and especially this AlphaChannel business. Remember I mentioned that on the Console app it is reported as Picture.HasAlphaChannel = True and on Desktop = False. Well I studied that a bit more and it seems there is a huge difference because when you open the file on Desktop, it does a premultiply of the alpha value with the RGBs, but when you open under console app, then it doesn’t.

So I tested it and the results were:
Console: Picture.RGBSurface.Pixel(1,1) = &cC6CABC00
and Picture.RGBSurface.Pixel(1,1).(Red,Green,Blue,Alpha) = (198, 202, 188, 0)

Desktop: Picture.RGBSurface.Pixel(1,1) = &cBABFAE00
and Picture.RGBSurface.Pixel(1,1).(Red,Green,Blue,Alpha) = (186, 191, 174, 0)

From what I understand the premultiply of the alpha is an adjustment to ensure the actual RGB pixels can be transferred to the graphic processor faster, so it is multiplied because the expectation is that the image will be shown on the screen at some stage. In the case of the console app, there is no chance of it being shown, therefore not needed. (my own thinking here)

I’ve also read that the multiplication process is a lossy process, so you cannot reverse it. But I assume it can be applied in one direction. So lets say it was already done to the Desktop Pixels, then I can also do it to the Console pixels and should always get the same result.

In anyway the difference is (R,G,B) = (12,11,14) between the 2 environments for the pixel shown above. But the alpha was reported as 0. So what was it multiplied with? It was (0,9393939…, 0.9455445…, 0.9255319…). So this gives no clue how to always treat and get the reversal. I tested this on 100 pixels and just compared the Red values, and found some inconsistencies, like when Red is 181, the Desktop red could be 169 or 165, or Console 184 gives Desktop 170 or 172. And alpha always shows as just 0. It seems there is something else which determines the resulting value.

Anybody who can shed light on this?

And anybody who can advise how to move this to another topic because this is really about the Alphachannel issue rather than the Horizontal Resolution.

8

You can change the topic at any time. Click on it to edit.

9

Thankks Michel, I updated the Topic to something more relevant

Just in case anybody is looking, using the Photoshop CS5 Extended Version 12.0, Photoshop reports exactly the same pixel RGB values as the ones found under the Console RGBSurface.Pixel.

So it is clear that when a Picture is loaded in Xojo Desktop environment, the RGB values of the Pixels are changed. (I’ve looked at some of Alwyn Bester’s code and it looks like the Picture.Mask.RGBSurface.Pixel stores something for the AlphaChannel.

I’ve looked at the Desktop Picture Mask even to see if there is something, but that Mask.RGBSurface.Pixel(x,y).Red reports a 0 for all pixels. On the console app, the Mask reports a NilException.

I think the biggest question remains:
How can I ensure that I get the same Pixel RGB values for the same image (jpeg) under both a console and desktop Xojo app?

Sub Question: Why would Console Picture report HasAlphaChannel = True, and Desktop App reports HasAlphaCHannel = False, and Console Picture do not have a Mask, while Desktop has a Mask of all 0’s.

10

Device Profiles may play into the difference since desktop will likely have one where console probably doesn’t.
And the color management functions of OS X would then play around with the values.
Photoshop mostly bypasses whatever the OS wants to do as Abobe has all their own code for loading images etc.
As for why they’d be different - different available graphics libraries.
Console apps can’t use everything that a desktop app can because they’re console apps and don’t have device contexts nor access to AppKit.
And color profiles may be in use here as well

11

Hi Norman

Thanks. I just checked and the RGB Value of &cBABFAE00 (Desktop) is exactly equal to sRGB IEC 61966-2.1 Color Profile color value of &cC6CABC00 (Console)

You are right on the money here. This sort of answers the original question. I can now move onto another question, being Color Profile Related.

All the other stuff was just Red Herrings.

So OK now the challenge lies in how to coerce the one area to use the same Color Space as the other, or worst case, how to write the code to do the Color Conversions between two color spaces.

12

Quite a while ago in a long thread https://forum.xojo.com/14794-image-colour-confused/20 I remember having discovered that Mac Desktop indeed pixel and RGBSurface.pixel do comply to the color profile. I did not find any way to compensate to get back the color coded in the picture file.

Maybe there is a way with declares or plugins to set the color profile to neutral, at least just while you get the color. Or to get the current profile values in order to compensate.

Of course on Windows where apparently the system does not fiddle with color rendition, values in the file match exactly what pixel does.

13

There could be a way to access the color information in non-compressed picture files by tapping directly into the image data.

I am sure I have seen a topic about that somewhere in the forum, so there are probably members that can help. Cannot locate it at the moment.

The idea is to load the picture in a memoryblock and access the data directly, so the system has no chance to distort it. Apparently, the PNG format is not too terribly complex :
https://en.wikipedia.org/wiki/Portable_Network_Graphics

There may be other formats that are simple enough as well to be accessed the same way. On Windows, BMP comes to mind. But it is rather unusual on Mac.

14

Hi Michel

I read through the other posting.

I think the long post was missing something:

When on Mac OSX desktop then when a picture is opened, the rgb values are converted to Generic RGB irrespective (and correctly) from the source profile or raw data.

However, when doing the same under the console app environment, it does not do this color space conversion. Make sense because you are not going to display it on the device.

So far I have not found anything simple to do a conversion with. Ideally I would like to change the desktop picture back to whatever color space it was in originally. But the picture and folderitems does not expose the color space info. Next best thing is to drop the console part and make it a long running desktop app. Then I will have the consistent treatment of the RGB values.

A further concern from those postings mentioned is the dullness factor after the conversions. I noticed that whites under preview were rather grey when plotted to Xojo canvas.

I did locate the math and explanation for the color space conversions, but it will not solve the dullness issue. Lots of matrix algebra which would make things slower.

For a better result you “physically” have to make the image brighter after loading the image but before loading into the canvas.

It could all be solved by the option to switch the picture load to the same as the desktop or console. There could be no problem with also doing a Generic rgb under the console picture open.

Can’t we request that somehow?

15

I forgot to add that my users could run from web, pc or mac, and if they switch, their results will be different from previously processed. Therefore the idea that desktop should switch back to original rgb values.

16

[quote=247250:@Koos Brandt]When on Mac OSX desktop then when a picture is opened, the rgb values are converted to Generic RGB irrespective (and correctly) from the source profile or raw data.
[/quote]

That is exactly the point. In Desktop the color profile is always applied at load time, then you no longer have access to the exact values coded in the original picture file.

I believe accessing the raw data as I described just above is the only way to go if you want to have the exact same values. Another way would be to use a Console helper.

One thing is for sure : as it stands, Xojo Desktop Mac cannot provide the same exact colors as Photoshop does.

Just file a Feature Request in Feedback.

17

Hi.

You will need to work with bitmaps at a much lower than what Xojo provides.

The MBS and / or the Einhuger plugins are probably your best bet here (especially if your want cross platform).

Kev

18

[quote=247253:@Kevin Gale]especially if your want cross platform).
[/quote]

Precisely, on Windows no color profile is applied to a loaded picture, whereas it is always the case in Xojo Desktop on Mac. I am not even sure MBS could go low enough in the system to escape that.

19

Both MBS & Einhuger can load and save pictures without touching a Xojo Picture object meaning you can get the raw decompressed pixel values. If you need to perform any ICC colour management of the input data you can use the MBS LCMS2 plugin. You only need to involve the Picture object if you want to display the pixels on screen or if you need to perform additional drawing and don’t have an alternative to the Xojo graphics commands.

If image processing needs to be performed on the pictures then I personally, would avoid the Xojo Picture object as much as possible as you cannot get a consistent result across platforms. There are other issues to deal with such as 7 bit alpha and the odd choice of planar format in console apps. It is, a bit of a mess.

Bjorn has a page on his web site that lists some of the peculiarities:
http://www.einhugur.com/Html/infos/premultiplied.html

20

Thanks Kevin and Michel

I am in the prototyping stage of an idea, so was not even convinced of Xojo as the right tool, but I have always work rather easily with the “Basic” languages, so Xojo is rather productive, until you run into something like this. It just seems that in this area it leaves much to be desired. Ok, maybe it creates opportunity for the plugin guys.

I have explored the MBS website for their components, but buying the whole lot to get access to just the image processing looks a bit steep as I am doing this as an indie. Maybe later

I will look at what Einhuger provides. I noticed his notes on the premultiplied before, especially when I was still thinking it was a AlphaChannel issue. Had a quick look and it seems like he is doing an amazing set of Picture processing things. Also other things like serialisation of classes, which I learned XOJO JSON was not good at, and I switched SQLite for now. At elast with them it seems you can get free demo stuff until you decide to use it really.

From all the investigation it looks like a standard conversion (in the background, not on the picture objects) to XYZ Color Space, and then to do the image processing on that would be a more efficient way to go. Was hoping to leave that kind of coding and testing until a bit later. Compared to the development effort and issues, the plugins would be a steal. But the time taken to review and decide is a completely different issue.

I am a bit concerned because it seems that I will be adding more processing cycles over a large image, and my “hope” of a single code base, or at least some shared code between the Desktop(Mac and Windows) and Background/Console, but also the iPad and Web, is quickly becoming a challenge.

For now it seems that I have spin wheel for the last few days on a technical issue which is not what I set out to do, and MBS and Einhuger has probably solved most of the issues over lots of late nights. Will just have to check them out in more detail.