mkazhdan / TextureSignalProcessing

Gradient-Domain Processing within a Texture Atlas
69 stars 13 forks source link

issue with texture stitching #7

Open SriGanesh130 opened 5 years ago

SriGanesh130 commented 5 years ago

created a .ply file from obj file using meshlab.Ran TextureStitching with mesh and composite texture and mask of that texture. it saying: [EXCEPTION] InitializeGridChartsActiveNodes: Node already covered

Tried with the partial textures too, its giving core dumped. Give me some suggestion about what is texture format specifier and confidence format specifier

mkazhdan commented 5 years ago

Would you be able to share your files?

SriGanesh130 commented 5 years ago

data contains input images, part unwraps, segmented mask :: data.zip

mkazhdan commented 5 years ago

Can you send the .ply file as well?

mkazhdan commented 5 years ago

Also, do you have a composite texture image?

SriGanesh130 commented 5 years ago

This is perfectly stitched texture, If I want to generate the composite texture from part textures from your algorithm, How to generate with high accuracy. data1.zip

mkazhdan commented 5 years ago

To use the algorithm, you need to provide three things:

  1. a textured mesh,
  2. a composite texture file, and
  3. a mask file. Given the consistent texture maps in the folder "unwraps", you can get a composite by iterating over the texels in the texture image and using the texel from the best "unwrap" image. A simple way to define "best" is to require that the texel be visible and, of all visible texels, it has a surface normal that is pointing most directly towards the camera. (e.g. it maximizes the dot-product between the normal and the negative camera direction).

Independently, you are getting a "Node already covered" error because the texture mapping in result.ply is not injective. In particular, triangles 1502 and 8389 map to the same triangle in texture space.

nikanfds commented 4 years ago

I'm having the same issue. and in my mesh there are patches that map to the same triangle on texture, therefore I need them to be the same color in 3D space. Is that possible?

mkazhdan commented 4 years ago

I'm afraid it's not supported at the moment. The current assumption is that independent patches are free to have colors assigned to them independently.

nikanfds commented 4 years ago

if I remove the duplicated patches (the ones correspond to the same triangle on 1024*1024 texture), therefore the mesh would have some holes; but then I can run it through your code and get the final processed texture, right? Then at the end I can put back the removed patches and give them the color based on the output of "TextureSignalProcessing"

mkazhdan commented 4 years ago

I believe that should work.

On February 4, 2020 4:51:41 PM EST, nikanfds notifications@github.com wrote:

if I remove the duplicated patches (the ones correspond to the same triangle on 1024*1024 texture), therefore the mesh would have some holes; but then I can run it through your code and get the final processed texture, right? Then at the end I can put back the removed patches and give them the color based on the output of "TextureSignalProcessing"

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/mkazhdan/TextureSignalProcessing/issues/7#issuecomment-582132905

NengQian commented 3 years ago

I have the same error message too. Is that no injective texture mapping the only reason for this error? Are there any methods to determine if my mesh and texture mapping is injective? If they are not injective, how to find which triangle face actually share the same uv? Thank you!

mkazhdan commented 3 years ago

Can you share your data?

mkazhdan commented 3 years ago

Also, can you try the newly posted code/executables? It should give you information about the two triangles causing trouble.

NengQian commented 3 years ago

@mkazhdan Thanks for your reply. The data is regarding our new project so I guess I cannot share the data now. I am using the TSP.x64.zip file in the repo, it was updated 17 month ago. Is it the newly posted one? It did not give me the information about the two triangles causing the trouble...

mkazhdan commented 3 years ago

It should be. When I do an ls -l in the directory I see a time-stamp from 9/29/20.

NengQian commented 3 years ago

I rechecked the date of the TSP.x64.zip file in the repo, it was updated on 2018. I guess this 9/29/20 could be the date your decompressed the executable file in your local computer?

I reran the TextureStitching.exe from that zip file, and it only gave me the error message: [EXCEPTION] InitializeGridChartsActiveNodes: Node already covered

Where can I find the newly posted one?

mkazhdan commented 3 years ago

I apologize. That was an old link to the executables. You should be able to grab the new executables from: http://www.cs.jhu.edu/~misha/Code/TextureSignalProcessing/TSP.x64.zip

NengQian commented 3 years ago

Thanks! Now it shows the error message properly with the triangle Ids.