Jpg textures in *.skp

soldatino

@soldatino said:

Yes, 0xFF, 0xD9

D9 ? - from what I find ont he JPEG format it's D8... ??

@soldatino said:

and (transforming always in lowcase) "tp:","j" and

what are you transforming to lower case? Isn't this something you should compare on a byte level?

@soldatino said:

The start point of the name of the default textures, because it have not "" before. I must to write a filenames table...
But due the garbage the scan has not 100% certainty.

Are you looking for more than just the JPEG data? Are you also trying to get the texture filename?
Getting just the JPEG data extracted should be possible to reliably do - but if you're trying to get other meta data out of the .skp, that might be more troublesome - depending on what you try to extract.

I apologize, my english is bad.
0xFF, 0xD8 are the bytes at the start of the file, that continues with some bytes including "j" and "if" for sure, but h-l case depending by the editor that generated the jpg.
0xFF, 0xD9 are the last bytes of the file and are important because I don't know the filesize.
After these bytes, SU writes a information block, where the presence of slashes and ".jpg" string means that the jpg original file was in the PC of the creator, differently, if they are not and you find "tp:" the file was downloaded from the web, and there is a url instead of a filename. If you find nothing and only ".jpg", the file is a SU texture in his folder.
Warning : the "name" is written n+chr$(0)+a+chr$(0)+m+chr$(0)+e+chr$(0)+. ......etc
Thank Tig and ThomThom for the infos, I will search for the API also.

AdamB

Perhaps you're getting confused by the fact that the strings are widechars (2 bytes per character).

thomthom

@soldatino said:

0xFF, 0xD9 are the last bytes of the file and are important because I don't know the filesize.

There is an signed/unsigned integer in the four bytes immediately before SOI that gives you the size of the image.

(which is lucky as the .skp format often don't give any indication of the various sizes of its blocks.)

@soldatino said:

Warning : the "name" is written n+chr$(0)+a+chr$(0)+m+chr$(0)+e+chr$(0)+. ......etc

This is because part of the .skp format is in Unicode format. (Though not all strings.)

I've attached my notes on the .skp format. It's far from complete, and is in some places wrong. (I think I found some new info last time I looked which I haven't written down in these notes yet.)
Also attached is a 010 template I use when poking around in the .skp format.

.skp file format information

soldatino

@thomthom said:

@soldatino said:

0xFF, 0xD9 are the last bytes of the file and are important because I don't know the filesize.

There is an signed/unsigned integer in the four bytes immediately before SOI that gives you the size of the image.

The size of image or the offset of the end of jpg file?

@thomthom said:

I've attached my notes on the .skp format. It's far from complete, and is in some places wrong. (I think I found some new info last time I looked which I haven't written down in these notes yet.)
Also attached is a 010 template I use when poking around in the .skp format.

Really interesting! I am finishing the first version (a couple of hours for interface) of my jpg extractor then I will study it!

jeff hammond

fwiw, you might want to check out file juicer for ideas:
http://echoone.com/filejuicer/

that apps extracts all image files from a .skp (file thumbnails, scene thumbnails, textures, images etc.) [and it will extract other file types if they happen to be in the .skp]

i made a post about this before in which i posted a sample output from a juiced .skp:
http://forums.sketchucation.com/viewtopic.php?p=276979#p276979

[edit] hmm.. maybe it's osx only.. surely there's something similar for windows?

thomthom

@soldatino said:

The size of image or the offset of the end of jpg file?

The size. After that 4 byte int, just read the next immediate chunk given that size and you should have your image.

soldatino

@unknownuser said:

fwiw, you might want to check out file juicer for ideas:
http://echoone.com/filejuicer/

that apps extracts all image files from a .skp (file thumbnails, scene thumbnails, textures, images etc.) [and it will extract other file types if they happen to be in the .skp]

Thaks, I think to add other types of files also. Usually they have the header that it is more legible than the JPG...

soldatino

ok, it'is working
http://www.imitidicthulhu.it/skp2jpg.zip
probably a lot of bugs ...
very slow on large file (I will improve the scan using blocks-buffer...)
and the filenames of jpg supplied by SketchUp have to clean from some starting characters (it need a table of SU files)

ps: at the end of each jpg there is garbage (SU notes)... but usefull for the debug, and it does not corrupt the file...

update 002 extract fast!
update 003 SU default Materials filenames fixed

soldatino

require 'sketchup.rb'
if( not file_loaded?("skp2jpg.rb") )
UI.menu("Plugins").add_item("skp2jpg execute"){UI.openURL("skp2jpg.exe")}
end
file_loaded("skp2jpg.rb")

this plugin run skp2jpg.exe in the drawing session (checked on XP)
skp2jpg.exe and 3Drgb.dll have to be in system32 or windows

soldatino

Current skp2jpg.exe version 5, same link
http://www.imitidicthulhu.it/skp2jpg.zip
allows you to extract PNG files also (checked with few SU models...)

EDIT version 5b (large PNGs slow fixed)

soldatino

skp2jpg Updated at version 7a
Some lost jpg now are succesfully extracted
All jpg filenames are saved, instead of xxx_num.jpg

soldatino

bug found!
if the model has two files primarily stored by the autor in two different folders but with the same filename the program is confused and fails attempting to save the two files ... I am working about it to fix this unusual but possible recurrence..

[EDIT] fixed in vers 0.0.8

soldatino

Added in the zip the stand alone utility T-Magnifier.
You can see better the selected picture that you study and/or edit.
This is the v.0, next I will add the Extract button about the current picture.
This trick requires SU 8, English or Italian languages
(skp2jpg.exe extracts actually only all the files of the SKP)
NOTE: not checked with SU version 8 Pro.

soldatino

another FIX in vers 0.0.8a http://www.imitidicthulhu.it/skp2jpg.zip

case : missing path, jpg file found in SU RootDir(?)
no slashes found, possible prefix to filename (at end of SU file block) = &FF &FE [&??] [&??]
it seems working, anyway a possible error involves only the exact filename...

thomthom

Yea - occasionally texture filenames doesn't have a path. The ones that bundle with SU never does.

soldatino

yes, this is now the way that I use to find the pointer of the jpg end.


DefStr endj
DefStr endjH
endj="."+chr$(0)+"j"+chr$(0)+"p"+chr$(0)+"g"+chr$(0)
endjH="."+chr$(0)+"J"+chr$(0)+"P"+chr$(0)+"G"+chr$(0)
DefStr slash1$ ; slash1$=chr$(0)+"/"+chr$(0)
DefStr slash2$ ; slash2$=chr$(0)+"\"+chr$(0)
DefStr slash3$ ; slash3$=chr$(&hFF)+chr$(&hFE)

then, looping block of 200 bytes, then, if the block has endj or endjH then, looping in the block


    hh$=File.ReadBinStr(1) ; rd=rd+1
    File1.WriteBinStr(hh$,1)
    if hh$="." then
      DoEvents
      npo=File.position
      hh$=File.ReadBinStr(6) ; File.Seek(File.Position-6,0)
      chh=REPLACESUBSTR$(hh$,CHR$(0),"")
      chh=LCASE$(chh)
      DoEvents
      IF chh="jpg" then
        File.Seek(File.Position-128,0)
        name$=File.ReadBinStr(134)
        slash1=INSTR(name$,slash1$)
        slash2=INSTR(name$,slash2$)
        slash3=INSTR(name$,slash3$)
        IF (slash1 + slash2 + slash3)<>0 THEN
           >>>  FOUND! Then I start the detailed search of the pointer...

and now I am waiting for the next file that will fail

thomthom

Are you sniffing out the image size instead of reading the integer in front of the image data?

thomthom

soldatino

I did not attempt to sniff the jpg size because the compress header has particularity different of other picture formats, it is not a true header, and I dont have enough knowledge about it.
But your screeen shot is very good. I only knew the FF+FE recurrence. Your confirmation is important for me, with your addictionally info also.
Thanks!
ps I now can improve the exact png filename also, that at this moment I did not still search...

thomthom

@soldatino said:

I did not attempt to sniff the jpg size because the compress header has particularity different of other picture formats, it is not a true header, and I dont have enough knowledge about it.

What header are you referring to?

I'm not sure if we are referring to the same thing - maybe this screenshot will help.