Murga-Projects Forums

Full Version: slicing images
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I noticed that green line of pixels at the bottom as well.

I'm having great luck with this function now:
It will resize large images and prevent most of the problems so far.

Code:
function load_callback(object)
-- mod of a function (and a piece) written by John Murga
fileName = fltk.fl_file_chooser("Choose an RGB image", "Image Files (*.{jpg,png})", nil, nil)
if fileName then
  if image1 then image1:uncache() end -- don't know if this is needed
  image1 = Fl_Shared_Image.get(fileName)
-- set a window (or an object) image property to the image data
  w:image(image1,ts*tc,ts*tc)
-- set the image data to the a resized copy of the image data  
  image1 = w:image():copy(ts*tc,ts*tc)  
-- get table of tiles getTiles  
  myImages = image1:getTiles(ts,ts)
-- parse tile table into image data of objects
  for key,value in ipairs(myImages) do
  if  key < 16 then
    tile[key-1]:image(value)
tile[key-1]:redraw()
end
end
scramble()
  scrambutt:label("load an image")
end
end


However I broke the game play functionality so I have to go back a few steps somewhere.

I  think I've still segfaulted, and I've got some weird crash logs.

Code:
Thread 0 Crashed:
0   <<00000000>>     0xffff08a0 __memcpy + 256 (cpu_capabilities.h:228)
1   murgaLua                0x000595a6 0x1000 + 361894
..etc..etc
7   murgaLua                0x0015cd53 Fl_Widget::do_callback() + 29
8   murgaLua                0x0009d252 0x1000 + 639570
..etc..etc
12  com.apple.HIToolbox     0x92def4d7 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
13  com.apple.HIToolbox     0x92deeb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
14  com.apple.HIToolbox     0x92df5f7c SendEventToEventTarget + 56

etc...etc..

Once I've got the game play back I'll see if those crashes persist.

We have a saying where I come from about people who make assumptions :-)

Juergen, in a fraction of the time that took to compose your response you could have checked the source ...

This would have demonstrated that no assumptions are being made about colour depth, as I actually added an additional PNG specifically test the different RGB type.

I haven't had time to look at this properly yet, but I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles.

Either way it segfaults, which it shouldn't, and sucks big time, so it's my priority one bug.

Cheers
JohnM
BTW ...

What I would suggest for this is :

+ Create an off-screen buffer of the required size (which is a multiple of the tile dimensions).
+ Draw the re-sized picture to this off-screen buffer.
+ Get the image for the off-screen buffer (which should be perfectly normal).
+ Call getTiles on this.

I'll try it myself if I get through all my mails.

Cheers
JohnM
That sounds reasonable. I'll test it out after dinner.
Thank you again.

JohnMurga Wrote:
We have a saying where I come from about people who make assumptions :-)

Juergen, in a fraction of the time that took to compose your response you could have checked the source ...

Now you are under the assumption that I had the code readily available at the time. ;-)

JohnMurga Wrote:
This would have demonstrated that no assumptions are being made about colour depth, as I actually added an additional PNG specifically test the different RGB type.

In the meantime I have looked into the code and saw that it is depth independent.

JohnMurga Wrote:
I haven't had time to look at this properly yet, but I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles.

After a first quick scan it looks like it doesn't matter. I first thought this also when I saw the code, but it looks like (if I haven't overlooked anything) that it truncates w()%xSize pixels at the right and h()%ySize lines at the bottom part of the image.

JohnMurga Wrote:
Either way it segfaults, which it shouldn't, and sucks big time, so it's my priority one bug.

I haven't had the time to look deeper into it, but have you checked if ld() is always !=0?

Juergen

I didn't test yet. I have to learn about the offscreen drawing functions first, and since I got kinda buzzed at dinner I lost my ability to grasp new concepts =op

There is one thing I'm curious about, though. You said "I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles". In this particular instance the dimensions of the picture are always divisible by the dimensions of the tiles because the dimensions of the picture are a multiple of the dimensions of the tiles.

A happy coincidence, though (or what seems to be a coincidence), is that your getTiles() seems to create the tiles from right to left, top to bottom, which is precisely the method I used to create the tiles in the interface. So the index of the image tiles table is the same as the index of the interface tiles, with the exception that I started at 0 and you start at 1

I've been wondering what other uses getTiles could have. Maybe an image map that is controlled by buttons rather than coordinates (buttons would be easier to program, i think). Maybe an image-based gui that is resizable, although I'm not sure if the images can be dynamically resized as a resizeable window is dragged.
Ok to test bugs see:

Working file:
murgaLua/examples/images/Globe.png

and

segfault file:
murgaLua/gfx/murgaLua.png

--------------------------------------------
I mangled that segfault file a dozen different ways.
The final difference between crash and no crash is that
segfault files load into photoshop with the initial layer set to "background".
If layers are flattened in photoshop, a working file will become a segfault file.

Files that work load into photoshop with the initial layer on "layer 0".
If that image is saved with a solid layer at the bottom, it segfaults.

If an alpha channel is then applied to that bottom layer and saved it works.

Ok here's something wierd.
It will segfault if the alpha channel is 100% solid.
I put a one pixel dot into the alpha channel.
It doesn't segfault.
Your last mod of the load function, Bill, initially sets the image on a separate window, resizing it at that time. The size of the copy therefore doesn't need to be specified.

Do you think setting the image to a hidden window first and then tiling that data does any help over tiling the original data? Logically I don't see any difference between the two methods, but if there is an improvement I already have a "preview" window implemented that can be used for this purpose. The script I have locally is becoming quite different than the last one posted, so after I do some experiments with John's suggestion I'm going to post the newer version.
I have now tested it a little bit and I can't get any segmentation faults (is there a png somewhere available that faults?)
I have tested mikes sliding puzzle and I haven't found any problems with RGB or RGBA png's.

Although in the previously posted source the following lines:

Code:
test = image1:data()
-- force d(3) to prevent problems with alpha channel
image2 = fltk:Fl_RGB_Image(test[1], test["w"], test["h"], 3, test["ld"])

will definitely not work, because it only "lies" to the Fl_RGB_Image constructor about the data, but doesn't actually change it.
image2=image1 works on my system without a problem. (If there is a png that pruduces a crash then could someone post it?)
Also if the picture should be scaled (and not cropped, which doesn't make sense since the program doesn't know which side it should crop) image1=image1:copy(math.floor(image1:w()),math.floor(image1:h())) would make sense.

Juergen

P.S.: On which OS have those tests been performed?

The path to a segfaulting file is: murgaLua/gfx/murgaLua.png
All my tests have been Mac based.

mikshaw Wrote:
Your last mod of the load function, Bill, initially sets the image on a separate window, resizing it at that time. The size of the copy therefore doesn't need to be specified.
Do you think setting the image to a hidden window first and then tiling that data does any help over tiling the original data?


I set  the image of the main window, the preview window
never did anything so I didn't even notice the code for it until you mentioned it.

When importing images for the iGame3D interface icons,
I had to place the image inside of a button and copy the image at the size I needed it
to be, else I ended up with icons bigger than my buttons.
I don't think just setting the size of the image actually resizes it.

Code:
  image1 = Fl_Shared_Image.get(fileName)
  image1:h(ts*tc); image1:w(ts*tc)


Doesn't do any resize to the image.
Adding:

Code:
  w:image(image1,ts*tc,ts*tc)
  image1 = w:image():copy(ts*tc,ts*tc)


gets the image resized. I could have added an object for that purpose, a button, whatever, but its easier to use the window as a storage device, since it can hold the image data and allow the copy just as easily.

If I don't resize then anything larger than 320 pixels crashes.

Pages: 1 2 3 4 5
Reference URL's