On Sat, Dec 5, 2015 at 3:24 PM, Anton Aylward <li...@antonaylward.com> wrote: > Again, speaking as someone who once wrote compilers and supporting > tools, that is not so.
Your analogy to that problem space just doesn't hold here. > A link editor does not need to know about that data its moving. in the > case of a compile link load cycle the link edit does not need to know > about the machine code. As far as its concerned those are just "blobs" > or data that can be treated as blocks. its only the linkages that its > concerned with. That's the whole point! It doesn't work like that. Assume a simple TIFF-based format like the Sony one. Suppose you come across a 16bit value encoded as a standard TIFF_SHORT that says 15346 (made up number). You don't know what that number means so when you rewrite the Copyright tag you just leave it alone. Well guess what that number may very well be the offset to a TIFF IFD (a subsection with more values) you didn't previously know about. When in the future we do understand what it means that link will be broken on that edited file. That's one of the many ways TIFF is a particularly bad format to edit and raw files make that even worse. There are absolute offsets everywhere and you don't even know which fields are actual data to be left alone and which fields are offsets that need to be adjusted after an edit. It's absolutely hopeless to try and edit one properly without a precise definition of the format which just doesn't exist. >I admit that your role with DT is to manipulate what's inside those >blobs, the image data, so the linkages are important to you in that they >are correctly maintained so as to lead you to the image data. I can >understand why you are touchy about this. But as I say, link editing is >an old and well established practice. We never manipulate anything. We only extract from the file what we need without altering it. And we're not touchy about any of this. Feel free to mangle your own files as much as you want. Just don't expect us to ever add special cases to darktable to handle what you break. It's not a particularly good idea and there are much better ways to handle this but feel free to keep doing what you are doing. >Let's make it clear: I'm not talking about editing the picture data in >the blobs. You obviously have an understanding of that data so as to be >able to manipulate the images as you do in DT. You keep saying this which just means you don't understand how these formats work. Editing the image data would probably be safer than editing the metadata. We understand exactly how the image data works and as long as you don't increase the size of those sections editing that data would work fine. >But the issue isn't about complete or incomplete and it isn't about >every last RAW file in existence. its about non-image data and its >about links. Its about adequately defined information. See the example above as to why unless you have *complete* understanding of what each field in the format does you will muck it up when you rewrite it. Exiftool is the best attempt I know of to understand everything and even that will have bugs. There's no point taking the risk when there are better options available. Pedro ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
