If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#61
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Mayayana
wrote: "Lewis" wrote | HEIF is an excellent format with many modern advantages. I'm guessing you're saying that because you use Apple and Apple told you so, because Apple is switching to it in iPhones. no, it's because it's much better, with files typically around half the size of a jpeg and with higher quality. apple is the first to use it. others will follow. First, it's a container format, not an image format. that's a feature, and a very important and useful one, particularly where non-destructive edits can be stored with the image. Something like docx or like various compound storage formats. not really. Second, the compression used seems to be very good, but is it totally non-lossy? That's not clear from what I've read. keep reading. both lossless and lossy are supported. Third, and this is a biggie, the compression is patented: https://www.hevcadvance.com/licensin...ng-information lots of things are patented. Apple is using a system that allows for flexibility like storing different copies of the same image in one container. that's not why they're using it and it's not apple's format either. heif is an industry standard format that apple *and* others currently support or will be supporting in the future. https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format High Efficiency Image File Format (HEIF, often pronounced heef) is a file format for individual images and image sequences. It was developed by the Moving Picture Experts Group (MPEG) and is defined by MPEG-H Part 12 (ISO/IEC 23008-12). And presumably they're paying the patent fees. presumably. But that's not needed for a basic file format. it's much more than a basic file format. that's the point. All that's needed is to develop the best possible compression for bitmaps and then make that format widely supported. Add a clear metadata storage system and it does everything that anyone could want, at least within the range of 24-bit color raster images. which is what heif/hevc is intended to do, and a *****load* more. But it needs to be a non-patented compression. Otherwise it can't be used by most of the people who would want to use it, like webmasters. start he https://github.com/nokiatech/heif |
Ads |
#62
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Lewis
writes: In message J. P. Gilliver (John) wrote: In message , Tim Streater writes: [] When attachments are emailed, some of the metadata goes with it: at least filename, creation and modification dates. This is all done using the content-disposition: header (see RFC 2183). When I send or receive attachments, I'm pretty sure no date information is included. Depends entirely on how you send them. If I send them as normal, using Turnpike, Outlook, or Thunderbird. If I want to retain dates, I make a zip file, which _does_ retain dates (though I'm not sure if more than one) with each file within. If I just save an attachment from Turnpike or Outlook, the file created gets a creation date of the instant it's extracted. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf You can be tough without being rude - Nick Clegg, 2014 July |
#63
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 06:31:41 +0000, Paul said:
Your Name wrote: On 2017-12-14 03:16:11 +0000, Wolf K said: That's what Open With is for. Open With is near useless if you don't know what the file actually is. You'd have to Open With with every app you have until you found one that could open it properly. If you don't have any tools, and are on a desert island, you use "Open With" "Wordpad" to figure out what something is. It's not that hard. Only if the file itself contains some clue within it as to what the document type is ... many don't bother with that, so you're stuck trying to open it in every app you have. |
#64
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Mayayana wrote:
"Lewis" wrote | HEIF is an excellent format with many modern advantages. | I'm guessing you're saying that because you use Apple and Apple told you so, because Apple is switching to it in iPhones. You can guess what you wish. First, it's a container format, not an image format. You can feel free to make that meaningless distinction if you want. While technically correct it is pointless. HEIF contains HEVC and H.264/MPEG-4 AVC and might contain a JPEG thumbnail (up to 4K resolution) for display purposes. It's not going to contain, for example, a GIF or BMP image. Second, the compression used seems to be very good, but is it totally non-lossy? That's not clear from what I've read. "Lossless images" is the new "vinyl is best" idiocy. Third, and this is a biggie, the compression is patented: https://www.hevcadvance.com/licensin...ng-information OHNOES!HOW DREADFUL! WE'VE NEVER EVER HAD A PATENTED FORMAT BEFORE except for, you know, all of them. Patents expire. If you're a FOSS moron you can wait the 17 years. Apple is using a system that allows for flexibility like storing different copies of the same image in one container. Which is part of the spec. | No one can force MS to make that public or standardize the structure. | | Well, that is certainly not true. | No? A company doesn't have a right to keep proprietary technologies secret? That is not what I said. You made a false and incorrect statement and I pointed out it was false. Perhaps you'd like to tell us the Coke recipe. Which has nothing to do with anything. Thanks for playing. -- Live long enough to become a problem to your kids. |
#65
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message J. P. Gilliver (John) wrote:
In message , Lewis writes: In message J. P. Gilliver (John) wrote: In message , Tim Streater writes: [] When attachments are emailed, some of the metadata goes with it: at least filename, creation and modification dates. This is all done using the content-disposition: header (see RFC 2183). When I send or receive attachments, I'm pretty sure no date information is included. Depends entirely on how you send them. If I send them as normal, using Turnpike, Outlook, or Thunderbird. If I want to retain dates, I make a zip file, which _does_ retain dates (though I'm not sure if more than one) with each file within. If I just save an attachment from Turnpike or Outlook, the file created gets a creation date of the instant it's extracted. And there are many ways (countless ways) to send attachments. Many of them are entirely transparent to the user, so without digging they may have no idea how they are sent or what metadata is preserved. -- NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01 |
#66
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Your Name wrote:
On 2017-12-14 06:31:41 +0000, Paul said: Your Name wrote: On 2017-12-14 03:16:11 +0000, Wolf K said: That's what Open With is for. Open With is near useless if you don't know what the file actually is. You'd have to Open With with every app you have until you found one that could open it properly. If you don't have any tools, and are on a desert island, you use "Open With" "Wordpad" to figure out what something is. It's not that hard. Only if the file itself contains some clue within it as to what the document type is ... many don't bother with that, so you're stuck trying to open it in every app you have. I have *many* techniques for file identification and disassembly. For example, I upload small files to virustotal.com, to provide "hints" in cases where the unpackers the AV tools have, can provide info I can use. Opening them in every app is *never* used. Not ever. I'm too lazy to do that :-) Doing that implies "the terrorists have won". Obviously, there are files with crypto applied, and no metadata hints or 4CC codes or anything in them. And unless you know of an app that definitely handles a wide range of crypto, you'd say "forget it". I don't even think I have any examples like that, unless I made them myself like this. dd if=/dev/random of=C:\gee_whats_this bs=512 count=10000 Feeding that to "all the apps" won't work for sure. I use files like that to test data compressors, to see if they handle the file properly. Paul |
#67
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 13:22:54 +0000, Mayayana said:
"Tim Streater" wrote | | The type of a file and which app you'd like it to open with are items | of file metadata and have no business being part of the filename. | | Many files have such type-identifiers included. E.g., a JPG file begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS .doc | | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". Mac users are not expected to understand anything about files. That's not the same as metadata. Resource forks died with the Classic versions of Mac OS (the very last version released was 9.2.2 in December 2001), although Mac OS X does know how deal with them. Resource forks are usually only used by applications - normal document / data files do not have resource forks, so they are not how the OS knows which application to open a document in. In the application, the resource fork does contain the information used to establish which application the document was created / modified in. Mac OS X applications do still have resources, but they're stored within a normal file structure, so aren't affected corruption issues .... although the extra folders and files (including Finder specific data files on disks or in Zip archives) may cause confusion for Windows users. Resource fork used to be a problem when Mac users emailed photos. If they didn't know to strip the Mac- specific prepended data they'd send a corrupt file. Nope, not a Mac user problem, and photos, being document / data files, don't normally have resources forks anyway. The application files emailed were corrupted by Windows (either the OS on the receiver's computer or the OS on the servers the file travelled through) not knowing how to handle the two forks. Applications files could also be corrupted by trying to transfer them on Windows formatted disks. Either way, this was easily worked around by first compressing the application file using a Mac archiving utility such as Compact Pro or StuffIt. |
#68
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 14:21:12 +0000, Wolf K said:
On 2017-12-14 00:24, Your Name wrote: On 2017-12-14 03:16:11 +0000, Wolf K said: On 2017-12-13 19:37, Your Name wrote: [...] * ... you can't rely on the OS to do that since a JPEG image file can actually be opened in a text editor as the file's data, even if it's rarely useful to do so. That's what Open With is for. Open With is near useless if you don't know what the file actually is. You'd have to Open With with every app you have until you found one that could open it properly. If we're talking about user convenience, I agree, showing a file's type as part of the filename is very useful. (But IMO a three-letter extension is too limited). There are many other useful conventions, eg, in icon design. These are converging on a common standard. I don't know about Windows, but Mac OS X can have at least four letter extensions (.tiff, .jpeg, .html for example). Perhaps a bigger issue is using the "." character as the separator (although some OSes apparently use a space instead, which is even worse). If we're talking about choosing a program to open a file, extenions aren't needed. It would be easy to ensure that Open With offers only programs that can open a given file without reference to an extension. Just standardise metadata (eg, as a series of slots, some which must be filled, others for dev or user options). Easy peasy. Perhaps, but that means establishing another new "standard" for developers to follow (not all files currently have such data within them). It also means the OS has to physically read the files to find out what they are, which maybe isn't so much of an issue with today's fast CPUs and storage drives, but could be for those using server-based storage via slow (or data capped) network / internet connections. BUT, Microsoft can't stick to anyone else's standard and always tries to make up their own ideas and then force everyone else to follow them. Internet Explorer being an obvious example that caused many headaches for web developers thanks to using it's own silly ideas rather than the establised HTML standard. |
#69
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Your Name
wrote: I don't know about Windows, but Mac OS X can have at least four letter extensions (.tiff, .jpeg, .html for example). longer than that. Perhaps a bigger issue is using the "." character as the separator (although some OSes apparently use a space instead, which is even worse). which oses would those be?? |
#70
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Your Name
wrote: Resource forks died with the Classic versions of Mac OS (the very last version released was 9.2.2 in December 2001), although Mac OS X does know how deal with them. no they didn't. resource forks are very much alive and are still used to this day on mac os x (although their use is declining). Resource forks are usually only used by applications - normal document / data files do not have resource forks, many of them did have resource forks. so they are not how the OS knows which application to open a document in. that part is correct. that information is the finder info. In the application, the resource fork does contain the information used to establish which application the document was created / modified in. nope. that's kept in the desktop database. Mac OS X applications do still have resources, but they're stored within a normal file structure, so aren't affected corruption issues ... although the extra folders and files (including Finder specific data files on disks or in Zip archives) may cause confusion for Windows users. mac os x apps are bundles, however, individual files can (and often do) have resource forks. Resource fork used to be a problem when Mac users emailed photos. If they didn't know to strip the Mac- specific prepended data they'd send a corrupt file. Nope, not a Mac user problem, and photos, being document / data files, don't normally have resources forks anyway. sometimes they did, however, losing the resource fork in a transfer did not corrupt the image itself. The application files emailed were corrupted by Windows (either the OS on the receiver's computer or the OS on the servers the file travelled through) not knowing how to handle the two forks. Applications files could also be corrupted by trying to transfer them on Windows formatted disks. Either way, this was easily worked around by first compressing the application file using a Mac archiving utility such as Compact Pro or StuffIt. no. |
#71
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Wolf K
wrote: On 2017-12-14 10:18, nospam wrote: In article , Tim Streater wrote: | The type of a file and which app you'd like it to open with are | items | of file metadata and have no business being part of the filename. | Many files have such type-identifiers included. E.g., a JPG file | begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS | .doc | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. the resource fork (which was optional, as was the data fork) held various resources. it was basically a miniature database. a zero-length file would have an empty data *and* resource fork. rare, but possible. Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). The Resource Fork contained structured data which was managed by the operating system which defined a wide variety of resource types (though applications could define there own). These included GUI elements like menu templates, window templates, dialog item lists, icons etc. as well as things like fonts, device drivers, executable code segments, keyboard layouts etc. The data fork contained anything the application which created the file wanted to put there and the application was responsible for interpreting and organizaing that data. Metadata wasn't stored in either fork. It was stored in the desktop database which was maintained by the finder. The advantage of the resource fork was simply that it made the mac much easier to program since datatypes used by the OS were entirely managed by the OS rather than the application (and it made it easier to customize the GUI of existing applications). The majority of files which one would actually want to distribute cross-platform would have only a data fork as files which made use of the resource fork were generally mac-only files anyways. The bigger problem back in the day was transferring mac files to another mac across another system (Windows, *nix, etc.) which didn't recognize the resource fork. Andre -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
#72
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Lewis
writes: In message Mayayana wrote: [] Second, the compression used seems to be very good, but is it totally non-lossy? That's not clear from what I've read. "Lossless images" is the new "vinyl is best" idiocy. [] No. "Vinyl is best" is based on (currently) unmeasurable perceptions. (Granted, _some_ of them - abstruse harmonic interactions perhaps - may come to light in time.) Lossless image compression is, in contrast, a measurable matter: an image, after compression and then expansion, can be compared to the original, and it can thus be clearly stated whether there is any loss or not. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf This was before we knew that a laboratory rat, if experimented upon, will develop cancer. [Quoted by] Anne ), 1997-1-29 |
#73
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article ,
Andre G. Isaak wrote: Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). The Resource Fork contained structured data which was managed by the operating system which defined a wide variety of resource types (though applications could define there own). These included GUI elements like menu templates, window templates, dialog item lists, icons etc. as well as things like fonts, device drivers, executable code segments, keyboard layouts etc. The data fork contained anything the application which created the file wanted to put there and the application was responsible for interpreting and organizaing that data. Metadata wasn't stored in either fork. It was stored in the desktop database which was maintained by the finder. a good summary. The advantage of the resource fork was simply that it made the mac much easier to program since datatypes used by the OS were entirely managed by the OS rather than the application (and it made it easier to customize the GUI of existing applications). it also meant that end users could easily modify existing apps (or even the system itself) by modifying and/or replacing resources, and in some cases, add (or remove) additional functionality. The majority of files which one would actually want to distribute cross-platform would have only a data fork as files which made use of the resource fork were generally mac-only files anyways. The bigger problem back in the day was transferring mac files to another mac across another system (Windows, *nix, etc.) which didn't recognize the resource fork. true, although standard file types (text, jpg, etc.), often stored extra stuff in the resource fork alongside the file data, including window size/position, scroll position, zoom level, etc., and if that's lost when transferring to another system, no big deal. it just uses the defaults. all three parts (data & resource forks plus finder info) could be combined into a single entity (macbinary) so that it could be hosted on non-mac system without losing anything which was normally done automatically by mac comms software and generally where compatibility issues arose because that blob was no longer a standard jpeg, text or whatever format anymore. |
#74
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Your Name wrote:
On 2017-12-14 14:21:12 +0000, Wolf K said: On 2017-12-14 00:24, Your Name wrote: On 2017-12-14 03:16:11 +0000, Wolf K said: On 2017-12-13 19:37, Your Name wrote: [...] * ... you can't rely on the OS to do that since a JPEG image file can actually be opened in a text editor as the file's data, even if it's rarely useful to do so. That's what Open With is for. Open With is near useless if you don't know what the file actually is. You'd have to Open With with every app you have until you found one that could open it properly. If we're talking about user convenience, I agree, showing a file's type as part of the filename is very useful. (But IMO a three-letter extension is too limited). There are many other useful conventions, eg, in icon design. These are converging on a common standard. I don't know about Windows, but Mac OS X can have at least four letter extensions (.tiff, .jpeg, .html for example). ..webarchive, .pages, .workflow… But AFAIR Windows is not limited to three-letter extensions either. Perhaps a bigger issue is using the "." character as the separator (although some OSes apparently use a space instead, which is even worse). Which ones? If we're talking about choosing a program to open a file, extenions aren't needed. It would be easy to ensure that Open With offers only programs that can open a given file without reference to an extension. Just standardise metadata (eg, as a series of slots, some which must be filled, others for dev or user options). Easy peasy. Perhaps, but that means establishing another new "standard" for developers to follow (not all files currently have such data within them). Unix “file” command already exist. It also means the OS has to physically read the files to find out what they are, which maybe isn't so much of an issue with today's fast CPUs and storage drives, but could be for those using server-based storage via slow (or data capped) network / internet connections. BUT, Microsoft can't stick to anyone else's standard and always tries to make up their own ideas and then force everyone else to follow them. Internet Explorer being an obvious example that caused many headaches for web developers thanks to using it's own silly ideas rather than the establised HTML standard. -- Chemical engineers do it in packed beds. |
#75
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 20:28:16 +0000, Andre G. Isaak said:
In article , Wolf K wrote: On 2017-12-14 10:18, nospam wrote: In article , Tim Streater wrote: | The type of a file and which app you'd like it to open with are | items | of file metadata and have no business being part of the filename. | Many files have such type-identifiers included. E.g., a JPG file | begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS | .doc | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. the resource fork (which was optional, as was the data fork) held various resources. it was basically a miniature database. a zero-length file would have an empty data *and* resource fork. rare, but possible. Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). snip Wrong. Purely data files, such as a JPEG image or Word document, did not have any resource fork at all, not even an empty one. They didn't need one because there are no resources. That's why if you try to open a data file in ResEdit it says there is no resource fork and asks if you want to add one. (An optional add-on did allow ResEdit to open the data fork). Mainly it was only applications that had resource forks. Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|