I guess my biggest worry is a new format that nobody can use (easily) and all the flap that will cause. Maybe getting the dcraw guy to agree to add it right away (no longer needs to be 'per camera') would help - or "we" release a conversion utility (yawn).
Yes. this is why I initially rejected the idea, and still have mixed feelings about it. My original point was that *if* we want to make raw reliably identifiable, we should do it right rather than playing tricks with file size.
But I've been thinking along these lines for a while, and the idea has grown on me. In the long run it should be better than the current raw, which is essentially a new format with every camera. Also, using this approach, conversion to actual DNG is trivial so it would be easy to offer a standalone utility and easy for others to support. It would also be easy to offer a batch convert option on camera. Would be slow, but unlike current DNG, you get to choose where the time is spent.
I suppose it could be added to the RAW menu as a 3rd option for how to store the image but ....
You'd want a straight framebuffer dump for debugging anyway, but I'd rename it to something like "debug raw".
Update : should we ask someone (philmoz?) with admin rights to move the last bunch of posts to a new thread
I agree
I didn't mean to derail the thread, but I think this is a worthwhile topic for discussion.
The raw processing and saving is currently all done in spytask, if I interpret it correctly.
If we would create a task for file writing
... and we would do the byteswap process in chunks
... then maybe we could achieve some parallelism (I assume write() does use DMA). But everything would need to be synchronized properly, which can be complicated.
Agreed to all. Would be an interesting experiment, but possibly a lot of work for little/no gain.
