I have read the data required to create a asc file image n from file and I would like to now display the image in my compiler. Is there something special I have to do to my raw file data for it to be a viewable asc picture?
a long, long, long time ago people made images in ascii.
You can view these in any large capacity text editor, like notepad++.
turn word wrap off. Small ones are still popular for instant messaging and email footers and such.
dunno what he means by display in compiler. You can print them to the screen in a program. Your IDE has a text editor so you can see them there.
they can be quirky to get them displayed. I can't seem to manage one here, though code tag would help..
Could be an a raster GIS file format developed by Esri:
https://en.wikipedia.org/wiki/Esri_grid
I think I remember seeing .asc files used used to transfer information...never used it or GIS, just remember it from when I was looking at JPEG2000 a while back.
@jonnin
Yes, I’ve written a few ASCII-image programs myself, back before GUI computing was a thing. Complete with colors and alternate text characters. I’ve even played with plan file animations and all kinds of variants.
“display in compiler” == use my compiler to compile a program that will display the image (in addition to just reading it from file)
@Grey Wolf
Could be. There are quite a few different files floating around with an .asc extension. Some of them are rather obscure.
ok. so do you want to see the image, or display it in code?
that looks like ye olde ".raw" file format to me -- rows, cols, rgb array. I don't really know how you are trying to display it here, but that is my current best guess. There are programs that can display .raw files so that isnt too hard to do. Displaying it yourself is a bit harder: you need at least the ability to doodle on the screen, even if its just the windows draw buffer or something simple like that.
raw does not have a spec; its a convention if its anything at all. The closest thing is indeed a tiff or uncompressed tga type file. You also see them with a .rgb extension.
wiki has an extensive ramble about it. https://en.wikipedia.org/wiki/Raw_image_format
and FWIW AVI uncompressed video is a series of raws (yea, its huge).
Thank you for the link. Now we know about the .raw format. What about .asc?
The three example lines you show, first is #row and #columns or vv? Second line are 913 blank delimited words, next only 38 (I assume a truncated record).
The closest thing is indeed a tiff
For sure it is not. TIFF stands for Tagged Image File Format and besides few implicit values all data is tagged. This allows to have several very different graphic formats encapsulated within a .tif file. What you present as example looks much simpler, no Image File Header, no hint about byte order, etc.
Why do you want to convert it? Just to display it as a picture? In that case you could use a viewer like https://www.irfanview.com/ Irfan claims to read .raw with it.
raw does not have a spec; its a convention if its anything at all.
Are you talking about 'raw' files from digital cameras and such i.e. the data dumped off of the image sensor with no processing? There are plenty of specs for them...not necessarily freely available.
Or are you talking just an ad hoc ASCII dump of image data?
I think the OP could give more detail about where the file originates or what spec was used to write the code they use to read the data. Also info about what platform they are using would be good.
Or are you talking just an ad hoc ASCII dump of image data
this, mostly. Some sensors provide exactly that, though actual (advanced) cameras tend to garble or compress or mess with it. There is a whole world of RGB, RGBX, BGR, greyscale, and similar straight byte dump image files. Again, we are just guessing... so far we have a small number of integers. Open the thing in a raw image viewer. If that works, we can proceed easily. If it does not, need to drop back and punt on the format, and find out what it really is. Or, check to see if widthxheight+ 8 or so bytes == the file size. If so, its likely a raw...
Okay, sorry I didn't get back with more information sooner.
The asc file had to be opened, read in, and stored in a class dynamic array. Then, it's scaled to fit the 0-255 pixel range of a ppm and then converted/saved to a ppm file.
It was a grayscale image of course due to having to set each r g b to the same value.
Now, I just have to figure out how to do a recursive call on a function to autofill part of the image with a certain color.
Well, good luck with that, since both your posts so far have shared absolutely no usable information about your project. Might as well tell use you need to flobbotz the bogometer using the XYZ method, and you are having trouble with the recursive part.
That's my bad. When I made the post, I would've had to post pretty much my entire main, class.cpp, and header file since I was completely lost, and that seemed like a douchey thing to do. And, believe it or not, reading what you all said actually made things click for me. So technically, you all gave me exactly what I needed, and I didn't have to risk point deduction for too much outside help on homework.
I'll mark it resolved, and then on Monday(the assignment due date), I'll post relevant code in case someone else ever has the same project or something similar.
Now, I just have to figure out how to do a recursive call on a function to autofill part of the image with a certain color.
If it's not for the joy to reinvent the wheel once more and on your own, I would suggest to delegate this task where it is solved since long (IrfanView for example). Currently I can not see any reason for a recursive call to recolour a Portable Pixelmap formated pic.
BTW, I assume you know this: http://netpbm.sourceforge.net/doc/libnetpbm.html
Thank you. I didn't know about that library at all actually.
And as far as not needing recursion, I was operating under the belief that the only way to auto-fill and boundary was with recursion. This is all news to me.