CODEWITHSUNDEEP
c++image-processingpixeltiff
Andrew Lam
Andrew Lam

Reputation: 1391

C/C++ LIBTIFF: Need to read pixel location of white and black pixels from BW TIFF files

I am fairly new to image processing using Visual C++, I am in search of a way that reads black and white TIFF files and writes the image as an array hex values representing 0 or 1, then get the location information of either 0 (black) or 1 (white).

After a bit of research on Google and an article here https://www.ibm.com/developerworks/linux/library/l-libtiff/#resources I have the following trivial questions, please do point me to relevant articles, there are so many that I couldn’t wrap my heads around them, meanwhile I will keep on searching and reading.

Is it possible to extract pixel location information from TIFF using LIBTIFF?

Again being new to all image formats, I couldn't help to think that an image is made up of a 2D array of hex values , is the bitmap format more appropriate? Thinking in that way makes me wonder if I can just write the location of “white” or “black” mapped from its height onto a 2D array. I want the location of either “black” or “white”, is that possible? I don’t really want an array of 0s and 1s that represents the image, not sure if I even need them.

TIFF Example of a 4 by 2 BW image:

Output to something like ptLocArray[imageHeight][imageWidth] under a function named mappingNonPrint()

or under a function named mappingPrint()

With LIBTIFF, in what direction/ways does it read TIFF files?

Ideally I would like TIFF file to be read vertically from top to bottom, then shifts to the next column, then start again from top to bottom. But my gut tells me that's a fairy tale, being very new to image processing, I like to know how TIFF is read for example a single strip ones.

Additional info

I think I should add why I want the pixel location. I am trying to make a cylindrical roll printer, using a optical rotary encoder providing a location feedback The height of the document represents the circumference of the roll surface, the width of the document represent the number of revolutions.

The following is a grossly untested logic of my ENC_reg(), pretty much unrelated to the image processing part, but this may help readers to see what I am trying to do with the processed array of a tiff image. i is indexed from 0 to imageHeight, however, each element may be an arbitrary number ranging from 0 to imageHeight, could be 112, 354 etc that corresponds to whatever the location that contains black in the tiff image. j is indexed from 0 to imageWidth, and each element there is also starting 0 to imageWidth. For example, ptLocArray[1][2] means the first location that has a black pixel in column 2, the value stored there could be 231. the 231st pixel counting from the top of column 2.

I realized that the array[imageHeight][] should be instead array[maxnum_blackPixelPerColumn], but I don't know how to count the number of 1s, or 0s per column....because I don't know how to convert the 1s and 0s in the right order as I mentioned earlier..

void ENC_reg()

{

if(inputPort_ENC_reg == true) // true if received an encoder signal

{ 

            ENC_regTemp ++; // increment ENC register temp value by one each time the port registers a signal

                if(ENC_regTemp == ptLocArray[i][j])
                {
                    Rollprint(); // print it
                    i++; // increment by one to the next height location that indicates a "black", meaning print

                    if (ENC_regTemp == imageHeight)
                    {
                    // Check if end of column reached, end of a revolution
                    j++; // jump to next column of the image (starting next revolution)
                    i = 0; // reset i index to 0, to the top of the next column
                    ENC_regTemp = 0; // reset encoder register temp to 0 for the new revolution
                    };
                };



            ENC_reg(); // recall itself;
        };
    }

Upvotes: 0

Views: 1460

Answers (1)

MvG
MvG

Reputation: 61027

As I read your example, you want two arrays for each column of the image, one to contain the numbers of rows with a black pixel in that column, the other with indices of rows with a white pixel. Right so far?

This is certainly possible, but would require huge amounts of memory. Even uncompressed, a single pixel of a grayscale image will take one byte of memory. You can even use bit packing and cram 8 pixels into a byte. On the other hand, unless you restrict yourself to images with no more than 255 rows, you'll have multiple bytes to represent each column index. And you'd need extra logic to mark the end of the column.

My point is: try working with the “array of 0s and 1s” as this should be both easier to accomplish, less demanding in terms of memory, and more efficient to run.

Upvotes: 1

Related Questions