Jpg textures in *.skp
-
@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!
-
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?
-
@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.
-
@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...
-
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 -
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 -
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)
-
skp2jpg Updated at version 7a
Some lost jpg now are succesfully extracted
All jpg filenames are saved, instead of xxx_num.jpg -
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
-
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.
-
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... -
Yea - occasionally texture filenames doesn't have a path. The ones that bundle with SU never does.
-
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
-
Are you sniffing out the image size instead of reading the integer in front of the image data?
-
-
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... -
@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.
-
@soldatino said:
I only knew the FF+FE recurrence. Your confirmation is important for me, with your addictionally info also.
Did you look at the text file I attached earlier? with notes on the format.
SketchUp File Format Reverse Engineering Attempt by Thomas Thomassen [thomas@thomthom.net] //////////////////////////////////////////////////////////////////////////////// /// BLOCKS ///////////////////////////////////////////////////////////////////// There are reoccuring patterns. Looks like block signatures. Blocks Signature; FF FE FF ?? The next byte gives the size of the block (or block name) If the UBYTE after the signature is not NULL then it appears to be a UTF-16LE string. UTF-16LE string signature? Many places there is no string, the ?? byte is just NULL. Some places (FF FF) indicates a new section or area. Bytes before that mark might be important. For the Material and Layer section there is four bytes with the total number of Materials and Layers. (FF FF) appear to be preseeded by four bytes. ID number/signature? Apart from the byte indicating the Unicode string there doesn't seem to be any bytes that indicates the size of the blocks. Looks like it's required to know the structure to read the file. Even just part of it. Due to plugins there could be extra information and blocks inserted. Components also complicates things as they appear as files within the file. Due to this you can not blindly scan for strings or byte sequences. What is the pattern to the file structure? How do you scan/skip to the interesting data reliably? /// THEORY ///////////////////////////////////////////////////////////////////// Blocks (Sections); 2 bytes - Signature (FF FF) 2 bytes - (Short) Block ID or VersionMap referance 2 bytes - (Short) Size of Block Name ? bytes (Size of Block Name) - Name of Block (ASCII) FF FE FF Signature indicates Sub-Blocks. (Blocks inside the sections) ================================================================================ TIME_T - 32-bit value representing date and time in C using the format 'MM/dd/yyyy hh;mm;ss'. time_t is a 32-bit integer representing the number of seconds since 01/01/1970 12;00 AM. ================================================================================ /// HEADER BLOCKS ////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////// /// SkechUp File ID //////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size (in characters) | 28 bytes (14 Unicode Characters) - 'SketchUp Model' +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// Version Number ///////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size | Variable Bytes (Block Name Size) - Version Number wrapped in curly brackets +------------------------------------------------------------------------------+ | 16 Bytes - ? (Random every time, even when doing a Save As) | | When doing a Save As the files should be identical, but this section of data | differs anyway. (Tested with a file doing Save As two times. Result was | three files with the same size but had differences in two areas of this data | chunk. +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// Time Stamp ///////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size (00) | 4 bytes - Timestamp of when file was saved. Appears to be UTC regardless of | locale. (TIME_T) +------------------------------------------------------------------------------+ /// VERSION MAP //////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 6 bytes - Section Sig (FF FF 00 00 0B 00) | 11 bytes - 'CVersionMap' +------------------------------------------------------------------------------+ ~~~ Repeat ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size | Variable Bytes (Block Name Size) - Name of Capability +------------------------------------------------------------------------------+ | 2 bytes - ? (Capability ID?) Relates to Short Int after Blocks. | 2 bytes - ? +------------------------------------------------------------------------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size | 36 Bytes (18 Unicode Characters) - 'End-Of-Version-Map' +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// Unknown Data /////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 16 Bytes - ? | 00 00 00 00 01 00 00 00 B0 04 00 00 | ! 01 or 03 | 00 00 00 | | Theory; 4 Ints | 4 bytes - ? (00 00 00 00) Unsigned Int; 0 | 4 bytes - ? (01 00 00 00) Unsigned Int; 1 | 4 bytes - ? (B0 04 00 00) Unsigned Int; 1200 | 4 bytes - ? (03 00 00 00) Unsigned Int; 3 OR (01 00 00 00) | +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// CDib Block ///////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 6 bytes - Section Sig (FF FF 03 00 04 00) | 4 bytes - 'CDib' +------------------------------------------------------------------------------+ | 4 bytes - ? (04 00 00 00) | 4 bytes - Unsigned Int - Size of Image Data (PNG file) | {PNG DATA} | 10 bytes - ? (01 00 00 00 00 00 00 00 00 00) +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// Camera ///////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size (00) +------------------------------------------------------------------------------+ | 6 bytes - Section Sig (FF FF 05 00 07 00) | 4 bytes - 'CCamera' +------------------------------------------------------------------------------+ | 139 bytes - ? +------------------------------------------------------------------------------+ +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size +------------------------------------------------------------------------------+ | 236 bytes - ? (!) Does not match for .skp files with V-Ray material +------------------------------------------------------------------------------+ //////////////////////////////////////////////////////////////////////////////// /// Materials ////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 4 bytes - Material Count +------------------------------------------------------------------------------+ | 6 bytes - Section Sig (FF FF 0C 00 09 00) | 9 bytes - 'CMaterial' +------------------------------------------------------------------------------+ | 2 bytes - ? (00 00) Or other data if the material has an attribute attached. +------------------------------------------------------------------------------+ ~~~ Repeat by number of Material Count ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /// Material Block ///////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size | Variable Bytes (Block Name Size) - Material Name +------------------------------------------------------------------------------+ | 1 byte - ? | 1 byte - ? | 1 byte - Red | 1 byte - Green | 1 byte - Blue | 1 byte - Alpha +------------------------------------------------------------------------------+ /// Unknown //////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | EMPTY +------------------------------------------------------------------------------+ | 21 bytes - Unknown +------------------------------------------------------------------------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //////////////////////////////////////////////////////////////////////////////// /// Layers ///////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 4 bytes - Layer Count +------------------------------------------------------------------------------+ | 6 bytes - Section Sig (FF FF 02 00 06 00) | 6 bytes - 'CLayer' +------------------------------------------------------------------------------+ | 2 bytes - ? (00 00) +------------------------------------------------------------------------------+ ~~~ Repeat by number of Layer Count ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /// Layer Block //////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | 3 bytes - Block Signature (FF FE FF) | 1 byte - Block Name Size | Variable Bytes (Block Name Size) - Layer Name +------------------------------------------------------------------------------+ | 1 byte - Visibility (00 or 01) | 1 byte - ? | 1 byte - ? +------------------------------------------------------------------------------+ /// Material Block ///////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | REF; Material Block | Material block name; Layer_{Layer Name} | 4 bytes - ? Extra bytes trailing the Layer Material Blocks. +------------------------------------------------------------------------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /// Unknown //////////////////////////////////////////////////////////////////// +------------------------------------------------------------------------------+ | EMPTY +------------------------------------------------------------------------------+ | 6 bytes - ? (0C 00 00 00 00) | 4 bytes - CEdge Count? (Unlikely. Return 18 on model with 12 edges) | 2 bytes - ? (FF FF) | 4 bytes - ? (02 00 05 00) | 5 bytes - 'CEdge' +------------------------------------------------------------------------------+ -
Yes I downloaded it but I did not found jpg blocks and I thought that the markers was the signature only for the structures of objects and the jpgs were an unexplored different attachment.
Addictionally I thought that SU maintained an area of overwriting for the jpg images in the file, because I find garbage (jpg started and not ended, but it is possible that I was wrong) and I got the idea of a single physical space of storage... -
@thomthom said:
@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.
[attachment=0:3ag13v96]<!-- ia0 -->SUMaterialStart.png<!-- ia0 -->[/attachment:3ag13v96]exactly I was talking of the header of the jpg file itself
updated 0.0.9
faster, filename's search uses only ("jpg" or "IEND" strings) + &FF&FE&FF pointer
Advertisement