problems with Magick::Pixels

Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

problems with Magick::Pixels

Post by Straton » 2017-11-04T08:37:12-07:00

Hi,

my last posting was 2013, where I successfully integrated ImageMagick for reading and writing 16-bit gray image files in my C++ software. Now I am working on a completely new version from scratch on. For some reason, I fail doing even the simplest things with ImageMagick and I don't know what happens. Any help would be much appreciated. Currently I am working with ImageMagick 7.0.7-0 Q16 x86_64 on a Mac.

Please have a look on this code (stripped down without error detection and other things, hopefully I introduced no issues doing this):

Code: Select all

Magick::Image img;
img.read("Mars_gray.tif");
Magick::Pixels view(img);
const uint16_t* pixels = view.getConst(0,0,img.columns(), img.rows());
for (int i=0; i<20; ++i)
{
  std::cout << i << ": " << (int)pixels[i] << " " << (int)pixels[i]/256 << std::endl;
}
Output is:

Code: Select all

0: 50432 197
1: 18245 71
2: 50432 197
3: 18245 71
4: 50176 196
5: 18244 71
6: 50432 197
7: 18245 71
8: 50688 198
9: 18246 71
10: 50944 199
11: 18247 71
12: 51200 200
13: 18248 71
14: 51200 200
15: 18248 71
16: 50944 199
17: 18247 71
18: 50432 197
19: 18245 71
If you have a look into the image (using for example Fitswork), the pixel values of the first image row start with

197, 197, 196, 197, 198, 199, 200, 200, 199, 197

Each of them is represented by a 2-byte-value, as expected. What the hell are the other two bytes (18245) following each pixel value?

You can download this image here: Mars_gray.tif. I created it for testing purposes and it is a special case, since I identify says

Code: Select all

Depth: 16/8-bit
Channel depth:
    Gray: 8-bit
With my true test images, identify says

Code: Select all

Depth: 16-bit
Channel depth:
    Gray: 16-bit
With those, things are even worse, i. e. then I recognize no correlation of above test prints with the pixel values I see in Fitswork at all. So let's start step by step. In all cases there is only 1 channel.

Best regards,
Stefan

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-04T08:47:55-07:00

IM v7 has many differences to IM v6. See http://www.imagemagick.org/script/porting.php . I suggest you stick with v6 until you are ready to upgrade to v7.
snibgo's IM pages: im.snibgo.com

Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

Re: problems with Magick::Pixels

Post by Straton » 2017-11-04T09:04:51-07:00

I am rewriting from scratch. On Mac, there isn‘t even a previous version. Since v7 was normally released, I see no reason not to use it. So I avoid any need to port later to v7.

In addition I thought my question was really simple, isn‘t it? All I want to do is read an image file and access the pixel data. Basically as described in https://www.imagemagick.org/Magick++/Pixels.html - but in my case it's even simpler, since I only need to handle 1-channel-images and all have depth 16.

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-04T09:52:12-07:00

Your code assumes the image, as read, has one channel.
snibgo's IM pages: im.snibgo.com

Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

Re: problems with Magick::Pixels

Post by Straton » 2017-11-04T10:12:17-07:00

yes? As said, I only need to handle a very restricted subset of image types. All have 1 channel, all have 16 bit depth. I use ImageMagick just because of the image format reading and writing capabilities, for no other reason. 2013 I reported bugs in the FITS format reading and writing, which have been fixed then.

So now I want to do the very same thing - read a 16 bit 1-channel gray image from TIF or FITS and access the pixel data.

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-04T10:41:23-07:00

Straton wrote:All have 1 channel, ...
Your code assumes this, but doesn't check. Perhaps the assumption is wrong. Your test suggests the assumption is wrong.
snibgo's IM pages: im.snibgo.com

Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

Re: problems with Magick::Pixels

Post by Straton » 2017-11-04T18:12:58-07:00

My original code includes such checks, including error checking. I cannot do more than say what I know. If you don't believe me, please download the image and check the number of channels.

User avatar
fmw42
Posts: 22109
Joined: 2007-07-02T17:14:51-07:00
Location: Sunnyvale, California, USA

Re: problems with Magick::Pixels

Post by fmw42 » 2017-11-04T18:56:21-07:00

I know nothing about coding in C++. But using EXIFTOOL to review your file's meta data, I think it is 3 channel data RGB with the same data in each channel. And it has a color profile. Perhaps I misunderstand what EXIFTOOL is saying.

exiftool -s -ee -g1 -u -n -D Mars_gray_preview.jpeg
---- ExifTool ----
- ExifToolVersion : 10.51
---- System ----
- FileName : Mars_gray_preview.jpeg
- Directory : .
- FileSize : 215498
- FileModifyDate : 2017:11:04 18:46:54-07:00
- FileAccessDate : 2017:11:04 18:47:13-07:00
- FileInodeChangeDate : 2017:11:04 18:46:54-07:00
- FilePermissions : 644
---- File ----
- FileType : JPEG
- FileTypeExtension : JPG
- MIMEType : image/jpeg
- ImageWidth : 960
- ImageHeight : 970
- EncodingProcess : 0
- BitsPerSample : 8
- ColorComponents : 3
- YCbCrSubSampling : 2 2
---- JFIF ----
0 JFIFVersion : 1 1
2 ResolutionUnit : 0
3 XResolution : 1
5 YResolution : 1
---- ICC-header ----
4 ProfileCMMType :
8 ProfileVersion : 0
12 ProfileClass : mntr
16 ColorSpaceData : RGB
20 ProfileConnectionSpace : XYZ
24 ProfileDateTime : 2014:06:04 17:43:56
36 ProfileFileSignature : acsp
40 PrimaryPlatform :
44 CMMFlags : 0
48 DeviceManufacturer :
52 DeviceModel :
56 DeviceAttributes : 1 0
64 RenderingIntent : 0
68 ConnectionSpaceIlluminant : 0.9642 1 0.82491
80 ProfileCreator :
84 ProfileID : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
---- ICC_Profile ----
- ProfileDescription : sRGB IEC61966-2-1 black scaled
- MediaBlackPoint : 0.01205 0.0125 0.01031
- MediaWhitePoint : 0.9642 1 0.82491
- ProfileCopyright : Dropbox, Inc.
- RedMatrixColumn : 0.43607 0.22249 0.01392
- GreenMatrixColumn : 0.38515 0.71687 0.09708
- BlueMatrixColumn : 0.14307 0.06061 0.7141
- RedTRC : (Binary data 64 bytes, use -b option to extract)
- GreenTRC : (Binary data 64 bytes, use -b option to extract)
- BlueTRC : (Binary data 64 bytes, use -b option to extract)
---- Composite ----
- ImageSize : 960x970
- Megapixels : 0.9312


Using IM 7 to strip the profile and convert to grayscale with:

Code: Select all

magick Mars_gray_preview.jpeg -strip -colorspace gray  Mars_gray_preview2.jpg
Then I get 1 channel:

exiftool -s -ee -g1 -u -n -D Mars_gray_preview2.jpg
---- ExifTool ----
- ExifToolVersion : 10.51
---- System ----
- FileName : Mars_gray_preview2.jpg
- Directory : .
- FileSize : 208398
- FileModifyDate : 2017:11:04 18:53:51-07:00
- FileAccessDate : 2017:11:04 18:54:07-07:00
- FileInodeChangeDate : 2017:11:04 18:53:51-07:00
- FilePermissions : 644
---- File ----
- FileType : JPEG
- FileTypeExtension : JPG
- MIMEType : image/jpeg
- ImageWidth : 960
- ImageHeight : 970
- EncodingProcess : 0
- BitsPerSample : 8
- ColorComponents : 1
---- JFIF ----
0 JFIFVersion : 1 1
2 ResolutionUnit : 0
3 XResolution : 1
5 YResolution : 1
---- Composite ----
- ImageSize : 960x970
- Megapixels : 0.9312

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-04T19:13:50-07:00

@Fred: you are looking at the preview JPEG, not the downloaded larger image.

@Straton: The contents of the file don't matter. You are looking at values after they have been read.

I suppose you are not using HDRI? Because then the "Quantum" data type isn't "uint16_t". What does "magick -version" say?
snibgo's IM pages: im.snibgo.com

User avatar
fmw42
Posts: 22109
Joined: 2007-07-02T17:14:51-07:00
Location: Sunnyvale, California, USA

Re: problems with Magick::Pixels

Post by fmw42 » 2017-11-04T19:48:01-07:00

@snibgo: It was the only image that had a link. So I thought that was what he asked us to review. But you know more about all this. So I will leave it to you to continue.

Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

Re: problems with Magick::Pixels

Post by Straton » 2017-11-05T03:45:13-07:00

C++ doesn't allow implicit conversion of pointer types. If Quantum wasn't 2-byte, above code wouldn't compile. No warning, just an error. Nevertheless:

Code: Select all

/opt/bin> ./magick  -version
Version: ImageMagick 7.0.7-0 Q16 x86_64 2017-08-29 http://www.imagemagick.org
Copyright: © 1999-2017 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI 
Delegates (built-in): bzlib fontconfig freetype jng jp2 jpeg lcms pangocairo png tiff xml zlib

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-05T05:03:59-07:00

Straton wrote:HDRI
That's a problem. Probably the problem. Your pixels are stored as floating point, not integer.

getConst returns a pointer to Quantum. This datatype is floating-point for HDRI. It isn't advised to make any assumptions about this; explicitly convert values as required.
snibgo's IM pages: im.snibgo.com

Straton
Posts: 22
Joined: 2013-01-21T16:13:23-07:00
Authentication code: 6789

Re: problems with Magick::Pixels

Post by Straton » 2017-11-05T05:50:40-07:00

If Quantum was different from uint16_t (like with float), the C++ compiler would issue an error. This is the reason that I use uint16_t instead of Quantum. It avoids any problems with configurations my code does not support anyway. So it is impossible that Quantum is float in my configuration. If you don't believe me, please try to compile that code:

Code: Select all

float* p;
uint16_t* a = p;
In addition my IDE's code completion confirms that Quantum is uint16_t in my configuration: https://www.dropbox.com/s/52ynw48tyhatk ... e.png?dl=0

snibgo
Posts: 9404
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: problems with Magick::Pixels

Post by snibgo » 2017-11-05T06:01:08-07:00

In that case, you are running more than one version of IM.

Running multiple versions isn't a problem, with care. But if you accidentally run multiple versions, you can expect problems.

I suggest you remove all versions of IM. Then install just one. Before you install, decide if you want HDRI or not.
snibgo's IM pages: im.snibgo.com

User avatar
dlemstra
Posts: 1386
Joined: 2013-05-04T15:28:54-07:00
Authentication code: 6789
Contact:

Re: problems with Magick::Pixels

Post by dlemstra » 2017-11-05T06:02:54-07:00

It looks like you are using header files that have HDRI disabled. And linking with a library that has HDRI enabled.
.NET + ImageMagick = Magick.NET https://github.com/dlemstra/Magick.NET, @MagickNET, Donate

Post Reply